远程 Oracle Linux 8 主机上安装的程序包受到 ELSA-2026-6571 公告中提及的多个漏洞影响。

    - scsi：target：iscsi：修复 iscsit_dec_session_usage_count() 中的释放后使用 (CKI Backport Bot) [RHEL-150417] {CVE-2026-23193}
    - nouveau：修复 ptr 存储周围的 instmem 争用条件 (Lyude Paul) [RHEL-111846] {CVE-2024-26984}
    - scsi：qla2xxx：修复造成双重释放的 bsg_done() (Ewan D. Milne) [RHEL-153405] {CVE-2025-71238}
    - netfilter：nf_tables：修复 nf_tables_addchain() 中的释放后使用 (Florian Westphal) [RHEL-153264] {CVE-2026-23231}

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

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

Rocky Linux 8 主机上存在安装的程序包，该程序包受到 CIQ crlsa-2026_6572 公告中提及的多个漏洞的影响。

    * 内核：nouveau：修复 ptr 存储周围的 instmem 争用条件 (CVE-2024-26984)

    * kernel：scsi：target:：iscsi：修复 iscsit_dec_session_usage_count() 中的释放后使用漏洞 (CVE-2026-23193)

    * kernel: kernel：通过 nf_tables_addchain() 中的使用后释放漏洞，可能导致特权提升或拒绝服务 (CVE-2026-23231)

    * 内核：Linux 内核 (qla2xxx)：导致拒绝服务和潜在特权提升的双重释放漏洞。(CVE-2025-71238)

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

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

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

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

    - ARM64 架构；

    - S390 架构；

    - 区块层子系统；

    - 加密 API；

    - DMA 引擎子系统；

    - GPU 驱动程序；

    - InfiniBand 驱动程序；

    - 以太网绑定驱动程序；

    - STMicroelectronics 网络驱动程序；

    - 网络驱动程序；

    - NVME 驱动程序；

    - SCSI 子系统；

    - USB over IP 驱动程序；

    - 文件系统基础设施；

    - Ext4 文件系统；

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

    - SMB 网络文件系统；

    - 内核线程帮助程序 (kthread)；

    - Distributed Switch 架构；

    - IPv6 联网；

    - Netfilter；

    - 跟踪基础设施；

    - 控制群组 (cgroup)；

    - Kernel exit() syscall；

    - Scatterlist API;

    - 内存管理；

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

    - 以太网桥接；

    - Ceph Core 库；

    - IPv4 联网；

    - MAC80211 子系统；

    - 多路径 TCP；

    - 数据包套接字；

    - RxRPC 会话套接字；

    - SMC 套接字；

    - TLS 协议；

    - Unix 域套接字；

    - X.25 network layer;

    - AppArmor 安全模块；(CVE-2025-71088, CVE-2025-71090, CVE-2025-71127, CVE-2025-71134, CVE-2025-71141, CVE-2025-71142, CVE-2025-71144, CVE-2025-71152, CVE-2025-71155, CVE-2026-22984, CVE-2026-23112, CVE-2026-23231, CVE-2026-23272, CVE-2026-23273, CVE-2026-23274, CVE-2026-23278, CVE-2026-23351, CVE-2026-23392, CVE-2026-23394, CVE-2026-23427, CVE-2026-23428, CVE-2026-23450, CVE-2026-23455, CVE-2026-31402, CVE-2026-31418, CVE-2026-31419, CVE-2026-31436, CVE-2026-31448, CVE-2026-31478, CVE-2026-31504, CVE-2026-31533, CVE-2026-31607, CVE-2026-31635, CVE-2026-31637, CVE-2026-31649, CVE-2026-31657, CVE-2026-31659, CVE-2026-31668, CVE-2026-31669, CVE-2026-31682, CVE-2026-31685, CVE-2026-31718, CVE-2026-43011, CVE-2026-43033, CVE-2026-43037, CVE-2026-43038, CVE-2026-43071, CVE-2026-43077, CVE-2026-43078, CVE-2026-43083, CVE-2026-43114, CVE-2026-43117, CVE-2026-43125, CVE-2026-43186, CVE-2026-43197, CVE-2026-43304, CVE-2026-43341, CVE-2026-43376, CVE-2026-43378, CVE-2026-43383, CVE-2026-43384, CVE-2026-43402, CVE-2026-43406, CVE-2026-43407, CVE-2026-43414, CVE-2026-43493, CVE-2026-43501, CVE-2026-45898, CVE-2026-45966, CVE-2026-45988, CVE-2026-46028, CVE-2026-46039, CVE-2026-46043, CVE-2026-46115, CVE-2026-46119, CVE-2026-46135, CVE-2026-46185, CVE-2026-46195, CVE-2026-46243, CVE-2026-46244, CVE-2026-46266, CVE-2026-46289, CVE-2026-46316, CVE-2026-46325)

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

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

远程 CentOS Linux 9 主机上存在安装的程序包该程序包受到 kernel-5.14.0-688.el9 版本变更日志中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane:
    nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. (CVE-2026-23231)

  - 已修复 Linux 内核中的下列漏洞：autofs: fix memory leak of waitqueues in autofs_catatonic_mode Syzkaller reports a memory leak: BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm syz-executor399, pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue structs should be freed if their wait_ctr becomes zero. Otherwise they will be lost. In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places.
    Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage counter to zero which is not a correct behaviour. edit:imk This description is of course not correct. The umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the autofs mount itself. They happen independently, usually after everything mounted within the autofs file system has been expired away. If everything hasn't been expired away the automount daemon can still exit leaving mounts in place. But expires done in both cases will result in a notification that calls autofs_wait_release() with a result status. The problem case is the summary execution of of the automount daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount is umounted. end edit: imk So in catatonic mode we should free waitqueues which counter becomes zero.
    edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode() was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is removed from the list when either of these two functions are called. Consequently the wait entry will be freed by only one of these functions or by the woken process in autofs_wait() depending on the order of the calls. end edit: imk (CVE-2023-54134)

  - 已修复 Linux 内核中的下列漏洞：mm: hugetlb: independent PMD page table shared count The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared.
    The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID:
    0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name:
    QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110
    __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table.
    1. The page table itself will be discarded after reporting the nonzero mapcount. 2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped. Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count. (CVE-2024-57883)

  - 已修复 Linux 内核中的下列漏洞：net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF. (CVE-2025-38180)

  - 已修复 Linux 内核中的下列漏洞：HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in
    _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510
    __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ?
    __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. (CVE-2025-39818)

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

Rocky Linux 8.6 主机上存在安装的程序包，该程序包受到 CIQ ciqsa-2026_1573 公告中提及的多个漏洞的影响。

    此公告汇总了 CIQ LTS 8.6中内核 SRPM 的安全修复。它解决了 15 个 CVE：
    CVE-2026-53002、 CVE-2026-43116、 CVE-2026-64268、 CVE-2026-80863和 CVE-2026-4312510 个。

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

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

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

  - 已修复 Linux 内核中的下列漏洞：capabilities: fix undefined behavior in bit shift for CAP_TO_MASK Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace:
    <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0
    __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> (CVE-2022-49870)

  - 已修复 Linux 内核中的下列漏洞：intel_th: Fix a resource leak in an error handling path If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function. (CVE-2022-50143)

  - 已修复 Linux 内核中的下列漏洞：xsk: Fix xsk_diag use-after-free error during socket cleanup Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND.
    The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic's netlink operation. (CVE-2023-53426)

  - 已修复 Linux 内核中的下列漏洞：VMCI: Fix use-after-free when removing resource in vmci_resource_remove() When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields. It is possible though to create two resources with different types but same handle (same context and resource fields). When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability. BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
    __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
    __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
    __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0 This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove(). (CVE-2024-46738)

  - 已修复 Linux 内核中的下列漏洞：tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it. (CVE-2024-50131)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
305605	Oracle Linux 8：内核 (ELSA-2026-6571)	Nessus	Oracle Linux Local Security Checks	2026/4/8	2026/5/19	high
355897	Rocky Linux 8 [CIQ] 安全更新：kernel-rt / kernel-rt-core / kernel-rt-debug / kernel-rt-debug-core / etc 多种漏洞（crlsa-2026_6572）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high
325425	Ubuntu 24.04 LTS：Linux (NVIDIA) 内核漏洞 (USN-8508-1)	Nessus	Ubuntu Local Security Checks	2026/7/7	2026/7/30	critical
304415	CentOS 9kernel-5.14.0-688.el9	Nessus	CentOS Local Security Checks	2026/3/31	2026/3/31	high
359534	Rocky Linux 8.6 [CIQ] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多种漏洞（ciqsa-2026_1573）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/6	high
360870	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1777633439）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high

检测

插件搜索

high

high

critical

high

high

high