遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2026:9513 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：smc：修正 __pnet_find_base_ndev() 中的釋放後使用弱點 (CVE-2025-40064)

    * 核心：smc：在 smc_clc_prfx_match() 中使用 __sk_dst_get() 和 dst_dev_rcu() (CVE-2025-40168)

    * kernel: net/sched: cls_u32：使用 skb_header_pointer_careful() (CVE-2026-23204)

    * 核心：核心：透過 nf_tables_addchain() 中的釋放後使用造成特權提升或拒絕服務 (CVE-2026-23231)

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 MiracleLinux 9 主機已安裝受到多個弱點影響的套件如 AXSA:2026-470:27 公告中所提及。

    * 核心：Linux 核心 (net/mlx5)：ECVF vport 卸載中的釋放後使用錯誤會導致拒絕服務 (CVE-2025-38109)
      * 核心：核心：透過反轉元素活動檢查，在 nf_tables 中發生特權提升或拒絕服務 (CVE-2026-23111)
      * 核心：Linux 核心：VSI 重建期間發生爭用情形，導致 ice 驅動程式中發生拒絕服務 (CVE-2026-23210)
      * 核心：核心：透過 nf_tables_addchain() 中的釋放後使用造成特權提升或拒絕服務 (CVE-2026-23231)

Tenable 已直接從 MiracleLinux 安全公告擷取前置描述區塊。

請注意，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-80863CVE-2026-43125、 和另外 10 個。

Tenable 已直接從 CIQ 安全性公告中擷取上述描述區塊。

請注意，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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 Ubuntu 24.04 LTS 主機上安裝的一個套件受到 USN-8508-1 公告中所提及的多個弱點影響。

    在 Linux 核心中發現數個安全性問題。攻擊者可能會利用這些弱點入侵系統。此更新可更正下列子系統中的瑕疵：

    - ARM64 架構;

    - S390 架構；

    - 區塊層子系統；

    - 密碼編譯 API;

    - DMA 引擎子系統；

    - GPU 驅動程式；

    - InfiniBand 驅動程式；

    - 乙太網路綁定驅動程式;

    - STMicroelectronics 網路驅動程式；

    - 網路驅動程式；

    - NVME 驅動程式；

    - SCSI 子系統；

    - USB over IP 驅動程式 ;

    - 檔案系統基礎架構；

    - Ext4 檔案系統；

    - 網路檔案系統 (NFS) 伺服器程序；

    - SMB 網路檔案系統；

    - 核心執行緒協助程式 (kthread)；

    - 分散式交換架構;

    - IPv6 網路；

    - Netfilter；

    - 追蹤基礎架構；

    - 控制群組 (cgroup);

    - 核心 exit() 系統呼叫；

    - 散點清單 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-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	名稱	產品	系列	已發布	已更新	嚴重性
309110	RHEL 8：核心 (RHSA-2026:9513)	Nessus	Red Hat Local Security Checks	2026/4/22	2026/5/5	high
309112	MiracleLinux 9kernel-5.14.0-611.47.1.el9_7 (AXSA:2026-470:27)	Nessus	Miracle Linux Local Security Checks	2026/4/22	2026/5/5	high
359534	Rocky Linux 8.6 [CIQ] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ciqsa-2026_1573）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/6	high
304415	CentOS 9kernel-5.14.0-688.el9	Nessus	CentOS Local Security Checks	2026/3/31	2026/3/31	high
325425	Ubuntu 24.04 LTS : Linux 核心 (NVIDIA) 弱點 (USN-8508-1)	Nessus	Ubuntu Local Security Checks	2026/7/7	2026/7/30	critical
360870	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1777633439）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high

偵測

搜尋 Plugin

high

high

high

high

critical

high