Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - md/raid10：修复丢弃失败时的writes_pending和屏障引用泄漏 raid10_make_request（） 在调用 raid10_handle_discard（） 之前通过 md_write_start（） 获取writes_pending引用。raid10_handle_discard（） 中的多个失败路径完成 bio 并在不释放相应引用的情况下返回，从而导致跳过 md_write_end（）。请在从这些失败路径返回之前调用 md_write_end（） 以保持writes_pending核算平衡。此外，在 wait_barrier（） 成功之后，可能会发生丢弃拆分分配失败。这些路径返回时不调用 allow_barrier（），从而泄露相关的屏障引用。在从这些路径返回之前释放屏障。（CVE-2026-72438）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

AlmaLinux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：2026：1791800936公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：kunit: Fix potential null dereference in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - 已修复 Linux 内核中的下列漏洞：arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d (CVE-2024-57878)

  - 已修复 Linux 内核中的下列漏洞：mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160) wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305) tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651) tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1)) ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254) ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ> This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address. In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - 已修复 Linux 内核中的下列漏洞：devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - 已修复 Linux 内核中的下列漏洞：drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Ubuntu 24.04 LTS 主机上安装的一个程序包受到 USN-8886-1 公告中提及的多个漏洞影响。

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - NVDIMM (Non-Volatile Memory Device) 驱动程序；

    - 握手 API；

    - ARM32 架构；

    - ARM64 架构；

    - MIPS 架构；

    - OpenRISC 架构；

    - PowerPC 架构；

    - S390 架构；

    - x86 架构；

    - 区块层子系统；

    - 加密 API；

    - 英特尔 NPU 驱动程序;

    - Android 驱动程序；

    - 雷达斯块设备 （RBD） 驱动程序;

    - 蓝牙驱动程序；

    - 硬件随机数发生器核心；

    - TPM 设备驱动程序；

    - CPU 频率缩放框架；

    - 硬件加密设备驱动程序；

    - DMA 引擎子系统；

    - FireWire 子系统；

    - Arm Firmware Framework for ARMv8-A(FFA)；

    - GPIO 子系统；

    - GPU 驱动程序；

    - HID 子系统；

    - 硬件监控驱动程序；

    - CoreSight HW 跟踪驱动程序;

    - I2C 子系统；

    - IIO ADC 驱动程序；

    - IIO 子系统；

    - InfiniBand 驱动程序；

    - 输入设备核心驱动程序；

    - 输入设备（鼠标）驱动程序；

    - IOMMU 子系统；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - 多功能设备驱动程序；

    - Fastrpc 驱动程序；

    - Amazon Nitro Secure Module 驱动程序;

    - MMC 子系统；

    - MTD 块设备驱动程序；

    - 以太网绑定驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - Texas Instruments 网络驱动程序；

    - NTB 驱动程序；

    - NVME 驱动程序；

    - NVMEM（非易失性内存）驱动程序；

    - Parport 驱动程序；

    - Pin 控制器子系统；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - 系统重置/关闭驱动程序;

    - PTP 时钟框架；

    - 电压和电流调节器驱动程序；

    - S/390 驱动程序；

    - SCSI 子系统；

    - SPI 子系统；

    - Realtek RTL8723BS SDIO 驱动程序；

    - VME 总线暂存驱动程序;

    - 热驱动程序；

    - Thunderbolt 和 USB4 驱动程序；

    - TTY 驱动程序；

    - DesignWare USB2 驱动程序;

    - USB Gadget 驱动程序；

    - USB 主机控制器驱动程序；

    - USB Dual Role (OTG-ready) Controller 驱动程序；

    - USB 串口驱动程序；

    - USB Type-C Port Controller Manager 驱动程序；

    - vDPA 驱动程序；

    - Virtio Host (VHOST) 子系统；

    - Framebuffer 层；

    - 监视程序驱动程序；

    - 9P 分布式文件系统；

    - AFS 文件系统；

    - 文件系统基础设施；

    - BTRFS 文件系统；

    - Ceph 分布式文件系统；

    - EROFS 文件系统；

    - exFAT 文件系统；

    - F2FS 文件系统；

    - FUSE（Userspace 中的文件系统）；

    - 块设备的日志层 (JBD2)；

    - 网络文件系统 (NFS) 客户端；

    - 网络文件系统 (NFS) 服务器后台程序；

    - NTFS3 文件系统；

    - OCFS2 文件系统；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - 跟踪文件系统；

    - UDF 文件系统；

    - XFS 文件系统；

    - 密钥管理；

    - BPF 子系统；

    - 控制群组 (cgroup)；

    - Glob模式匹配库;

    - MAC80211 子系统；

    - Mellanox 驱动程序；

    - Networking 核心；

    - 网络套接字；

    - IPv6 联网；

    - 蓝牙子系统；

    - 无线网络；

    - IPv4 联网；

    - Netfilter；

    - 网络流量控制；

    - SCTP 协议；

    - TCP 网络协议；

    - XFRM 子系统；

    - RDMA verbs API；

    - io_uring 子系统；

    - IPC 子系统；

    - 审计子系统；

    - 内核 CPU 基础架构；

    - Perf 事件；

    - Kernel exit() syscall；

    - Kernel fork() syscall；

    - 计划程序基础设施；

    - 信号处理机制；

    - Timer 子系统；

    - 跟踪基础设施；

    - 可调整大小的哈希表库;

    - 内存管理；

    - 6LoWPAN网络协议;

    - 异步传输模式 (ATM) 子系统；

    - B.A.T.M.A.N. 网格协议；

    - 以太网桥接；

    - CAN 网络层；

    - Ceph Core 库；

    - Ethtool 驱动程序；

    - HSR 网络协议；

    - IEEE802154.4 网络协议；

    - IUCV 驱动程序；

    - KCM（Kernel Connection Multiplexor）套接字驱动程序；

    - IEEE 802.15.4 子系统；

    - 多路径 TCP；

    - Open vSwitch；

    - 数据包套接字；

    - Phonet 协议；

    - 高通IPC路由器（QRTR）;

    - RDS 协议；

    - RxRPC 会话套接字；

    - SMC 套接字；

    - Sun RPC 协议；

    - TIPC 协议；

    - TLS 协议；

    - Unix 域套接字；

    - VMware vSockets 驱动程序；

    - X.25 network layer;

    - eXpress 数据路径；

    - AppArmor 安全模块；

    - 完整性度量架构 (IMA) 框架；

    - SELinux 安全模块；

    - ALSA 框架；

    - HD-audio 驱动程序；

    - QCOM ASoC 驱动程序；

    - 简单的音频多路复用器编解码器驱动程序;

    - Texas InstrumentS Audio (ASoC/HDA) 驱动程序；

    - SoC Audio for Freescale CPU 驱动程序；

    - Amlogic Meson SoC 驱动程序；

    - SOF 驱动程序；

    - NVIDIA Tegra ASoC 驱动程序;

    - USB 音频设备；

    - 表演工具;

    - KVM子系统;（CVE-2025-37807 ， ， ， CVE-2026-43022， CVE-2026-46321CVE-2026-53267CVE-2026-53160CVE-2026-53161CVE-2026-53136CVE-2026-53137CVE-2026-52994CVE-2026-53143CVE-2026-53138CVE-2026-53146CVE-2026-53147CVE-2026-53149CVE-2026-53156CVE-2026-53157CVE-2026-52947CVE-2026-53189CVE-2026-53184CVE-2026-53194CVE-2026-53195CVE-2026-53199CVE-2026-53202CVE-2026-53205CVE-2026-52943CVE-2026-53223CVE-2026-53209CVE-2026-53229CVE-2026-53253CVE-2026-53255CVE-2026-53268CVE-2026-53272CVE-2026-52942CVE-2026-53330CVE-2026-53329CVE-2026-53389CVE-2026-53388CVE-2026-53390CVE-2026-53387CVE-2026-53383CVE-2026-53381CVE-2026-53391CVE-2026-53366CVE-2026-53365CVE-2026-53362CVE-2026-53392CVE-2026-53356CVE-2026-52935CVE-2026-53397CVE-2026-63794CVE-2026-53402CVE-2026-63802CVE-2026-53401CVE-2026-63803CVE-2026-63805CVE-2026-46322CVE-2026-52923CVE-2026-63806CVE-2026-52917CVE-2026-52927CVE-2026-52929CVE-2026-53400CVE-2026-23265、 、 、 CVE-2026-64005CVE-2026-63869CVE-2026-63867CVE-2026-63870CVE-2026-63875CVE-2026-63879CVE-2026-63881CVE-2026-63884CVE-2026-63833CVE-2026-63909CVE-2026-63889CVE-2026-63913CVE-2026-63920CVE-2026-63925CVE-2026-63927CVE-2026-63930CVE-2026-63827CVE-2026-63954CVE-2026-63942CVE-2026-63968CVE-2026-63970CVE-2026-63971CVE-2026-63985CVE-2026-64002CVE-2026-63824CVE-2026-64004CVE-2026-64003CVE-2026-64009CVE-2026-64017CVE-2026-64023CVE-2026-64239CVE-2026-64222CVE-2026-64210CVE-2026-64242CVE-2026-64189CVE-2026-64188CVE-2026-64123CVE-2026-64243CVE-2026-64095CVE-2026-64036CVE-2026-64026CVE-2026-64245CVE-2026-63823CVE-2026-63817CVE-2026-64277CVE-2026-64272CVE-2026-64276CVE-2026-64266CVE-2026-64270CVE-2026-64271CVE-2026-64274CVE-2026-64279CVE-2026-63819CVE-2026-64273CVE-2026-63816CVE-2026-64246CVE-2026-63814CVE-2026-63812CVE-2026-63809、 、 、 CVE-2026-64418CVE-2026-64322CVE-2026-64323CVE-2026-64324CVE-2026-64318CVE-2026-64368CVE-2026-64333CVE-2026-64372CVE-2026-64374CVE-2026-64375CVE-2026-64378CVE-2026-64379CVE-2026-64317CVE-2026-64388CVE-2026-64380CVE-2026-64389CVE-2026-64395CVE-2026-64398CVE-2026-64401CVE-2026-64402CVE-2026-64312CVE-2026-64411CVE-2026-64403CVE-2026-64412CVE-2026-64413CVE-2026-64420CVE-2026-64443CVE-2026-64442CVE-2026-64440CVE-2026-64444CVE-2026-64436CVE-2026-64435CVE-2026-64432CVE-2026-64448CVE-2026-64430CVE-2026-64423CVE-2026-64422CVE-2026-64449CVE-2026-64304CVE-2026-64298CVE-2026-64532CVE-2026-64469CVE-2026-64524CVE-2026-64456CVE-2026-64463CVE-2026-64468CVE-2026-64496CVE-2026-64533CVE-2026-64299CVE-2026-64481CVE-2026-64296CVE-2026-64452CVE-2026-64287CVE-2026-64286CVE-2026-64283、 、 、 CVE-2026-68104CVE-2026-64563CVE-2026-64567CVE-2026-64568CVE-2026-64560CVE-2026-64574CVE-2026-64570CVE-2026-64576CVE-2026-64577CVE-2026-64578CVE-2026-64580CVE-2026-64581CVE-2026-64556CVE-2026-64583CVE-2026-64582CVE-2026-64584CVE-2026-64585CVE-2026-64599CVE-2026-64600CVE-2026-68091CVE-2026-64550CVE-2026-68097CVE-2026-68096CVE-2026-68098CVE-2026-68100CVE-2026-68106CVE-2026-68131CVE-2026-68129CVE-2026-68125CVE-2026-68140CVE-2026-68121CVE-2026-68119CVE-2026-68118CVE-2026-68141CVE-2026-68116CVE-2026-68108CVE-2026-68107CVE-2026-68142CVE-2026-64547CVE-2026-64545CVE-2026-68179CVE-2026-68153CVE-2026-68178CVE-2026-68145CVE-2026-68148CVE-2026-68149CVE-2026-68157CVE-2026-68189CVE-2026-64546CVE-2026-68155CVE-2026-64543CVE-2026-68143CVE-2026-64540CVE-2026-64539CVE-2026-64536、 、 、 CVE-2026-68329CVE-2026-68253CVE-2026-68255CVE-2026-68258CVE-2026-68245CVE-2026-68262CVE-2026-68260CVE-2026-68263CVE-2026-68266CVE-2026-68273CVE-2026-68284CVE-2026-68287CVE-2026-68236CVE-2026-68293CVE-2026-68290CVE-2026-68294CVE-2026-68297CVE-2026-68299CVE-2026-68314CVE-2026-68315CVE-2026-68222CVE-2026-68322CVE-2026-68320CVE-2026-68323CVE-2026-68326CVE-2026-68335CVE-2026-68373CVE-2026-68371CVE-2026-68370CVE-2026-68376CVE-2026-68354CVE-2026-68353CVE-2026-68352CVE-2026-68377CVE-2026-68348CVE-2026-68340CVE-2026-68338CVE-2026-68383CVE-2026-68219CVE-2026-68204CVE-2026-68402CVE-2026-68398CVE-2026-68401CVE-2026-68391CVE-2026-68392CVE-2026-68397CVE-2026-68400CVE-2026-68404CVE-2026-68216CVE-2026-68399CVE-2026-68202CVE-2026-68389CVE-2026-68199CVE-2026-68196CVE-2026-68192、 、 、 CVE-2026-72049CVE-2026-68446CVE-2026-68447CVE-2026-68451CVE-2026-68445CVE-2026-68453CVE-2026-68452CVE-2026-68454CVE-2026-68466CVE-2026-68467CVE-2026-68471CVE-2026-68474CVE-2026-68442CVE-2026-72005CVE-2026-68479CVE-2026-72009CVE-2026-72012CVE-2026-72019CVE-2026-72021CVE-2026-72024CVE-2026-68433CVE-2026-72035CVE-2026-72029CVE-2026-72036CVE-2026-72045CVE-2026-72051CVE-2026-72072CVE-2026-72067CVE-2026-72066CVE-2026-72089CVE-2026-72061CVE-2026-72057CVE-2026-72055CVE-2026-72099CVE-2026-72054CVE-2026-72053CVE-2026-72052CVE-2026-72102CVE-2026-68432CVE-2026-68419CVE-2026-72116CVE-2026-72110CVE-2026-72115CVE-2026-72107CVE-2026-72108CVE-2026-72109CVE-2026-72114CVE-2026-72117CVE-2026-68425CVE-2026-72113CVE-2026-68417CVE-2026-72105CVE-2026-68414CVE-2026-68409CVE-2026-68408、 、 、 CVE-2026-72233CVE-2026-72146CVE-2026-72148CVE-2026-72149CVE-2026-72144CVE-2026-72160CVE-2026-72157CVE-2026-72162CVE-2026-72164CVE-2026-72165CVE-2026-72170CVE-2026-72171CVE-2026-72136CVE-2026-72175CVE-2026-72172CVE-2026-72181CVE-2026-72195CVE-2026-72196CVE-2026-72197CVE-2026-72213CVE-2026-72135CVE-2026-72227CVE-2026-72225CVE-2026-72231CVE-2026-72232CVE-2026-72235CVE-2026-72261CVE-2026-72254CVE-2026-72253CVE-2026-72262CVE-2026-72252CVE-2026-72250CVE-2026-72247CVE-2026-72282CVE-2026-72244CVE-2026-72243CVE-2026-72242CVE-2026-72284CVE-2026-72133CVE-2026-72122CVE-2026-72330CVE-2026-72304CVE-2026-72314CVE-2026-72298CVE-2026-72301CVE-2026-72302CVE-2026-72312CVE-2026-72334CVE-2026-72123CVE-2026-72310CVE-2026-72121CVE-2026-72297CVE-2026-72120CVE-2026-72119CVE-2026-72118、 、 、 CVE-2026-72435CVE-2026-72373CVE-2026-72374CVE-2026-72375CVE-2026-72371CVE-2026-72382CVE-2026-72378CVE-2026-72389CVE-2026-72390CVE-2026-72397CVE-2026-72400CVE-2026-72404CVE-2026-72369CVE-2026-72406CVE-2026-72405CVE-2026-72409CVE-2026-72410CVE-2026-72416CVE-2026-72418CVE-2026-72419CVE-2026-72352CVE-2026-72423CVE-2026-72420CVE-2026-72425CVE-2026-72427CVE-2026-72438CVE-2026-72470CVE-2026-72469CVE-2026-72464CVE-2026-72476CVE-2026-72460CVE-2026-72459CVE-2026-72450CVE-2026-72478CVE-2026-72449CVE-2026-72444CVE-2026-72440CVE-2026-72480CVE-2026-72350CVE-2026-72343CVE-2026-74270CVE-2026-74256CVE-2026-74262CVE-2026-72485CVE-2026-72492CVE-2026-72502CVE-2026-74258CVE-2026-74281CVE-2026-72347CVE-2026-74257CVE-2026-72342CVE-2026-72483CVE-2026-72340CVE-2026-72338CVE-2026-72335、 、 、 CVE-2026-74378CVE-2026-74300CVE-2026-74312CVE-2026-74313CVE-2026-74297CVE-2026-74317CVE-2026-74314CVE-2026-74321CVE-2026-74330CVE-2026-74334CVE-2026-74338CVE-2026-74340CVE-2026-74296CVE-2026-74344CVE-2026-74341CVE-2026-74347CVE-2026-74349CVE-2026-74356CVE-2026-74359CVE-2026-74363CVE-2026-74295CVE-2026-74374CVE-2026-74365CVE-2026-74375CVE-2026-74377CVE-2026-74380CVE-2026-74446CVE-2026-74444CVE-2026-74443CVE-2026-74450CVE-2026-74438CVE-2026-74397CVE-2026-74390CVE-2026-74453CVE-2026-74388CVE-2026-74387CVE-2026-74385CVE-2026-74454CVE-2026-74294CVE-2026-74292CVE-2026-74481CVE-2026-74469CVE-2026-74479CVE-2026-74461CVE-2026-74465CVE-2026-74467CVE-2026-74471CVE-2026-74482CVE-2026-74293CVE-2026-74470CVE-2026-74289CVE-2026-74456CVE-2026-74288CVE-2026-74283CVE-2026-74282、 、 、 CVE-2026-74557CVE-2026-74512CVE-2026-74515CVE-2026-74516CVE-2026-74510CVE-2026-74519CVE-2026-74518CVE-2026-74522CVE-2026-74523CVE-2026-74527CVE-2026-74530CVE-2026-74531CVE-2026-74509CVE-2026-74534CVE-2026-74533CVE-2026-74535CVE-2026-74536CVE-2026-74537CVE-2026-74540CVE-2026-74544CVE-2026-74508CVE-2026-74549CVE-2026-74548CVE-2026-74550CVE-2026-74551CVE-2026-74563CVE-2026-74580CVE-2026-74579CVE-2026-74578CVE-2026-74581CVE-2026-74575CVE-2026-74574CVE-2026-74572CVE-2026-74582CVE-2026-74567CVE-2026-74565CVE-2026-74564CVE-2026-74583CVE-2026-74507CVE-2026-74496CVE-2026-74595CVE-2026-74589CVE-2026-74594CVE-2026-74586CVE-2026-74587CVE-2026-74588CVE-2026-74592CVE-2026-74597CVE-2026-74497CVE-2026-74590CVE-2026-74492CVE-2026-74584CVE-2026-74490CVE-2026-74488CVE-2026-74485、 、 、 CVE-2026-74649CVE-2026-74611CVE-2026-74612CVE-2026-74613CVE-2026-74610CVE-2026-74615CVE-2026-74614CVE-2026-74616CVE-2026-74621CVE-2026-74624CVE-2026-74625CVE-2026-74626CVE-2026-74609CVE-2026-74630CVE-2026-74628CVE-2026-74631CVE-2026-74632CVE-2026-74634CVE-2026-74635CVE-2026-74637CVE-2026-74608CVE-2026-74646CVE-2026-74641CVE-2026-74647CVE-2026-74648CVE-2026-74651CVE-2026-74669CVE-2026-74668CVE-2026-74667CVE-2026-74670CVE-2026-74666CVE-2026-74663CVE-2026-74662CVE-2026-74675CVE-2026-74661CVE-2026-74660CVE-2026-74656CVE-2026-74678CVE-2026-74607CVE-2026-74605CVE-2026-74696CVE-2026-74690CVE-2026-74695CVE-2026-74687CVE-2026-74688CVE-2026-74689CVE-2026-74692CVE-2026-74697CVE-2026-74606CVE-2026-74691CVE-2026-74604CVE-2026-74684CVE-2026-74603CVE-2026-74601CVE-2026-74598、 、 、 CVE-2026-80540CVE-2026-74720CVE-2026-74723CVE-2026-74724CVE-2026-74717CVE-2026-74726CVE-2026-74725CVE-2026-74730CVE-2026-74733CVE-2026-74736CVE-2026-74737CVE-2026-74739CVE-2026-74715CVE-2026-74744CVE-2026-74743CVE-2026-74746CVE-2026-74747CVE-2026-74748CVE-2026-74752CVE-2026-80521CVE-2026-74714CVE-2026-80527CVE-2026-80526CVE-2026-80528CVE-2026-80536CVE-2026-80541CVE-2026-80555CVE-2026-80554CVE-2026-80553CVE-2026-80556CVE-2026-80552CVE-2026-80551CVE-2026-80550CVE-2026-80557CVE-2026-80549CVE-2026-80548CVE-2026-80547CVE-2026-80558CVE-2026-74713CVE-2026-74710CVE-2026-80574CVE-2026-80568CVE-2026-80572CVE-2026-80560CVE-2026-80561CVE-2026-80565CVE-2026-80570CVE-2026-80576CVE-2026-74711CVE-2026-80569CVE-2026-74705CVE-2026-80559CVE-2026-74704CVE-2026-74701CVE-2026-74700、 、 、 CVE-2026-80585CVE-2026-80587CVE-2026-80589CVE-2026-80901CVE-2026-97509CVE-2026-80584CVE-2026-80721CVE-2026-80583CVE-2026-80586CVE-2026-80580CVE-2026-80579CVE-2026-80578

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Rocky Linux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1791800936公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：kunit: Fix potential null dereference in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - 已修复 Linux 内核中的下列漏洞：arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d (CVE-2024-57878)

  - 已修复 Linux 内核中的下列漏洞：mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160) wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305) tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651) tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1)) ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254) ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ> This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address. In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - 已修复 Linux 内核中的下列漏洞：devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - 已修复 Linux 内核中的下列漏洞：drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：1789898700公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：ceph: fix possible deadlock when holding Fwb to get inline_data 1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... } The inline_version will be 1, which is the initial version for the new create file. And here the ci->i_inline_version will keep with 1, it's buggy. 3, buffer write to the file immediately:
    ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1. 4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients. While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr). It's deadlock! URL:
    https://tracker.ceph.com/issues/55377 (CVE-2022-49296)

  - 已修复 Linux 内核中的下列漏洞：tracing: Fix reading strings from synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field char file[] will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open:
    file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open:
    file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open:
    file=/usr/lib/rpm/fileattrs/debuginfo.attr (CVE-2022-50255)

  - 已修复 Linux 内核中的下列漏洞：hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. (CVE-2023-52615)

  - 已修复 Linux 内核中的下列漏洞：fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> __schedule+0x2f6/0xb80 schedule+0x67/0xe0 fscache_wait_on_volume_collision.cold+0x80/0x82 __fscache_acquire_volume+0x40d/0x4e0 erofs_fscache_register_volume+0x51/0xe0 [erofs] erofs_fscache_register_fs+0x19c/0x240 [erofs] erofs_fc_fill_super+0x746/0xaf0 [erofs] vfs_get_super+0x7d/0x100 get_tree_nodev+0x16/0x20 erofs_fc_get_tree+0x20/0x30 [erofs] vfs_get_tree+0x24/0xb0 path_mount+0x2fa/0xa90 do_mount+0x7c/0xa0
    __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Considering that wake_up_bit() is more selective, so fix it by using wait_on_bit() instead of wait_var_event() to wait for the freeing of relinquished volume. In addition because waitqueue_active() is used in wake_up_bit() and clear_bit() doesn't imply any memory barrier, use clear_and_wake_up_bit() to add the missing memory barrier between cursor->flags and waitqueue_active(). (CVE-2023-52982)

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: ISO: fix iso_conn related locking and validity issues sk->sk_state indicates whether iso_pi(sk)->conn is valid. Operations that check/update sk_state and access conn should hold lock_sock, otherwise they can race. The order of taking locks is hci_dev_lock > lock_sock > iso_conn_lock, which is how it is in connect/disconnect_cfm -> iso_conn_del -> iso_chan_del. Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sock around updating sk_state and conn. iso_conn_del must not occur during iso_connect_cis/bis, as it frees the iso_conn. Hold hdev->lock longer to prevent that. This should not reintroduce the issue fixed in commit 241f51931c35 (Bluetooth: ISO: Avoid circular locking dependency), since the we acquire locks in order.
    We retain the fix in iso_sock_connect to release lock_sock before iso_connect_* acquires hdev->lock.
    Similarly for commit 6a5ad251b7cd (Bluetooth: ISO: Fix possible circular locking dependency). We retain the fix in iso_conn_ready to not acquire iso_conn_lock before lock_sock. iso_conn_add shall return iso_conn with valid hcon. Make it so also when reusing an old CIS connection waiting for disconnect timeout (see __iso_sock_close where conn->hcon is set to NULL). Trace with iso_conn_del after iso_chan_add in iso_connect_cis: =============================================================== iso_sock_create:771:
    sock 00000000be9b69b7 iso_sock_init:693: sk 000000004dff667e iso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1 iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_connect:875: sk 000000004dff667e iso_connect_cis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hci_get_route:1199: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:da iso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e __iso_chan_add:214: conn 00000000daf8625e iso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12 iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16 iso_sock_clear_timer:117: sock 000000004dff667e state 3 <Note: sk_state is BT_BOUND (3), so iso_connect_cis is still running at this point> iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16 hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535 hci_conn_unlink:1102: hci0: hcon 000000007b65d182 hci_chan_list_flush:2780: hcon 000000007b65d182 iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_shutdown:1434:
    sock 00000000be9b69b7, sk 000000004dff667e, how 1 __iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7 <Note: sk_state is BT_CONNECT (5), even though iso_chan_del sets BT_CLOSED (6). Only iso_connect_cis sets it to BT_CONNECT, so it must be that iso_chan_del occurred between iso_chan_add and end of iso_connect_cis.> BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name:
    QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:__iso_sock_close (net/bluetooth/iso.c:664) bluetooth =============================================================== Trace with iso_conn_del before iso_chan_add in iso_connect_cis:
    =============================================================== iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504 hci_dev_put:1487: hci0 orig refcnt 21 hci_event_packet:7607: hci0: e ---truncated--- (CVE-2023-54164)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 内核 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
335510	Linux Distros 未修补的漏洞：CVE-2026-72438	Nessus	Misc.	2026/8/15	2026/11/7	high
365209	Amazon Linux 2023：bpftool6.12、kernel6.12、kernel6.12-devel （ALAS2023-2026-3193）	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/11/2	medium
365767	Ubuntu 26.04 LTS：Linux 内核漏洞 (USN-8887-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
365258	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/29	high
364689	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1791800936）	Nessus	Alma Linux Local Security Checks	2026/10/12	2026/10/13	high
365457	Ubuntu 24.04 LTS：Linux (NVIDIA Tegra) 内核漏洞 (USN-8886-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	high
365463	Ubuntu 26.04 LTS：Linux 内核 (OEM) 漏洞 (USN-8889-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	medium
365768	Ubuntu 26.04 LTS：Linux kernel (Azure) 漏洞 (USN-8888-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
364682	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1791800936）	Nessus	Rocky Linux Local Security Checks	2026/10/12	2026/10/13	high
351155	Debian dsa-6528：ata-modules-6.12.111+deb13-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
360912	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.2：CLSA-2026：1789898700）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
362907	Debian dla-4817：ata-modules-6.12.107+deb12-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high

检测

插件搜索

high

high

medium

medium

high

high

high

medium

medium

high

high

high

high