AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1793333110 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - 已解決 Linux 核心中的下列弱點：USB: sisusbvga: Add endpoint checks The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - 已解決 Linux 核心中的下列弱點：net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. (CVE-2024-26740)

  - 已解決 Linux 核心中的下列弱點：mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - 已解決 Linux 核心中的下列弱點：vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

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

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1792445930 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). (CVE-2024-57793)

  - 已解決 Linux 核心中的下列弱點：crypto: af_alg - zero initialize memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures. A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data. (CVE-2025-71113)

  - 已解決 Linux 核心中的下列弱點：rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example (CVE-2026-31630)

  - 已解決 Linux 核心中的下列弱點：netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - 已解決 Linux 核心中的下列弱點：drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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

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

    據發現，某些 Arm 處理器可以在全域觀察到透過無效轉譯進行的記憶體寫入之前，完成廣播轉譯後備緩衝區 （TLB） 無效化。本機攻擊者可能會在撤銷許可權後使用此功能寫入記憶體，繞過記憶體保護或提升權限。（CVE-2025-10263）

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

    - ARM64 架構；

    - 使用者空間 API (UAPI);

    - 核心建置系統;

    - ARM32 架構；

    - PowerPC 架構；

    - RISC-V 架構；

    - S390 架構 ;

    - 使用者模式 Linux (UML) ;

    - x86 架構;

    - 密碼編譯 API;

    - 英特爾 NPU 驅動程式;

    - 計算加速架構;

    - ACPI 驅動程式；

    - 驅動程式核心；

    - DRBD 分散式複制區塊裝置驅動程式；

    - Rados 區塊裝置 （RBD） 驅動程式;

    - Ublk 使用者空間區塊驅動程式；

    - 壓縮 RAM 區塊裝置驅動程式；

    - 藍牙驅動程式;

    - 硬體加密裝置驅動程式；

    - CXL (Compute Express Link) 驅動程式；

    - 適用於 ARMv8-A(FFA) 的 Arm 韌體架構；

    - EFI 核心；

    - FPGA 架構；

    - GPU 驅動程式；

    - HID 子系統 ;

    - 硬體監控驅動程式 ;

    - I2C 子系統 ;

    - I3C 子系統 ;

    - InfiniBand 驅動程式 ;

    - 輸入裝置核心驅動程式;

    - 輸入裝置 (滑鼠) 驅動程式；

    - IOMMU 子系統;

    - 多個裝置驅動程式；

    - 媒體驅動程式 ;

    - Fastrpc 驅動程式；

    - 網路驅動程式；

    - Mellanox 網路驅動程式 ;

    - Microsoft Azure 網路介面卡 (MANA) 驅動程式；

    - MediaTek 網路驅動程式；

    - NVME 驅動程式；

    - 作業效能值 (OPP) 驅動程式;

    - PCI 子系統；

    - PTP 時鐘架構；

    - RPMSG 子系統；

    - SCSI 子系統；

    - SoundWire 子系統；

    - SPI 子系統；

    - Greybus lights staging 驅動程式；

    - 媒體演示驅動程式；

    - NVIDIA Tegra 嵌入式控制器 （NVEC） 暫存驅動程式;

    - Realtek RTL8723BS SDIO 驅動程式；

    - TCM 子系統；

    - 受信任執行環境驅動程式；

    - Thunderbolt 和 USB4 驅動程式 ;

    - TTY 驅動程式；

    - USB Gadget 驅動程式；

    - USB Dual Role (OTG-ready) 控制器驅動程式；

    - USB 序列驅動程式；

    - vDPA 驅動程式;

    - VFIO 驅動程式 ;

    - Virtio Host (VHOST) 子系統;

    - Virtio 驅動程式；

    - Xen Hypervisor 驅動程式；

    - 9P 分散式檔案系統 ;

    - AFS 檔案系統;

    - 檔案系統基礎架構；

    - BTRFS 檔案系統 ;

    - Ceph 分散式檔案系統；

    - AexFAT 檔案系統；

    - F2FS 檔案系統；

    - GFS2 檔案系統；

    - HFS 檔案系統；

    - HFS+ 檔案系統；

    - JFS 檔案系統；

    - 網路檔案系統程式庫；

    - 網路檔案系統 (NFS) 用戶端；

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

    - NTFS3 檔案系統；

    - OCFS2 檔案系統；

    - OrangeFS 檔案系統；

    - SMB 網路檔案系統；

    - BPF 子系統；

    - 檔案系統加密 （fscrypt）;

    - 軟體節點和裝置屬性;

    - IPv4 網路；

    - KVM 子系統;

    - Mellanox 驅動程式；

    - 記憶體管理；

    - 網路核心；

    - Netfilter；

    - 通訊端訊息基礎架構 ;

    - MediaTek SoC 驅動程式；

    - Sun RPC 通訊協定；

    - 網路流量控制；

    - IPv6 網路；

    - Amateur Radio 驅動程式；

    - 藍牙子系統；

    - IP 通道定義；

    - KCM (核心連線多工器) 通訊端驅動程式 ;

    - 多重通訊協定標籤交換驅動程式；

    - TCP 網路通訊協定；

    - XFRM 子系統；

    - 追蹤基礎架構；

    - io_uring 子系統；

    - 控制群組 (cgroup);

    - Perf 事件；

    - IRQ 子系統；

    - 鎖定基元 ;

    - KProbes 跟蹤;

    - 9P 檔案系統網路通訊協定；

    - B.A.T.M.A.N. 網狀通訊協定；

    - 乙太網路橋接器；

    - CAN 網路層

    - Ceph Core 程式庫；

    - 交握 API；

    - HSR 網路通訊協定；

    - IFE 協議;

    - L2TP 通訊協定；

    - MAC80211 子系統；

    - IEEE 802.15.4 子系統;

    - 多重路徑 TCP;

    - NFC 子系統 ;

    Open vSwitch；

    - Phonet 通訊協定；

    - RDS 通訊協定;

    - RxRPC 工作階段通訊端；

    - SCTP 通訊協定；

    - SMC 通訊端;

    - TIPC 通訊協定；

    - TLS 通訊協定；

    - Unix 網域通訊端;

    - VMware vSockets 驅動程式；

    - 無線網路 ；

    - X.25 network layer;

    - eXpress 資料路徑；

    - Rust 繫結機制；

    - AppArmor 安全性模組 ;

    - 金鑰管理；

    - Linux 安全性模組 (LSM) 架構；

    - SELinux 安全性模組；

    - ALSA 架構;

    - AudioScience HPI 驅動程式；

    - Intel ASoC 驅動程式;

    - USB音響設備;（CVE-2024-14040 ， ， ， CVE-2024-41008， CVE-2024-43872CVE-2025-38498CVE-2025-21985CVE-2025-22104CVE-2024-57857CVE-2024-58089CVE-2024-56591CVE-2024-58098CVE-2024-58094CVE-2024-58100CVE-2024-58241CVE-2025-21687CVE-2025-21693CVE-2025-21984CVE-2024-56552CVE-2025-22109CVE-2025-22108CVE-2025-23132CVE-2025-37776CVE-2025-37876CVE-2025-37906CVE-2025-38064CVE-2024-53098CVE-2025-38187CVE-2025-38069CVE-2025-38204CVE-2025-38206CVE-2025-38242CVE-2025-38563CVE-2025-38565CVE-2024-52560CVE-2025-38717CVE-2025-38636CVE-2025-40025CVE-2025-39990CVE-2025-40040CVE-2025-39958CVE-2025-39933CVE-2025-39896CVE-2025-40054CVE-2025-39862CVE-2025-39859CVE-2025-39789CVE-2025-40064CVE-2025-39677CVE-2024-50217CVE-2025-40074CVE-2025-40168CVE-2025-40158CVE-2025-40170CVE-2025-40139CVE-2025-40203CVE-2025-40274CVE-2024-44932CVE-2024-49932CVE-2025-40344CVE-2024-44964CVE-2024-49940CVE-2024-50106CVE-2025-40075CVE-2024-35948、、、 CVE-2026-43213CVE-2026-23239CVE-2026-23208CVE-2026-23240CVE-2026-23327CVE-2026-23393CVE-2026-23469CVE-2026-31420CVE-2025-71289CVE-2026-31486CVE-2026-31479CVE-2026-31493CVE-2026-31560CVE-2026-31568CVE-2026-31630CVE-2026-31663CVE-2025-71202CVE-2026-43009CVE-2026-31771CVE-2026-43029CVE-2026-43042CVE-2026-43048CVE-2026-43101CVE-2026-43116CVE-2025-71074CVE-2026-43172CVE-2026-43126CVE-2026-43263CVE-2026-43303CVE-2026-43352CVE-2026-46158CVE-2026-46130CVE-2026-46054CVE-2026-46170CVE-2026-45944CVE-2026-45932CVE-2026-45894CVE-2026-46175CVE-2026-45850CVE-2026-43464CVE-2026-43353CVE-2026-46181CVE-2025-71073CVE-2025-68745CVE-2026-52910CVE-2026-46324CVE-2026-52909CVE-2026-46275CVE-2026-46315CVE-2026-46320CVE-2026-52908CVE-2026-52912CVE-2025-68822CVE-2026-46330CVE-2025-68360CVE-2026-46203CVE-2025-68304CVE-2025-68174CVE-2025-40354、 、 、 、 CVE-2026-53159CVE-2026-52988CVE-2026-52956CVE-2026-53000CVE-2026-52991CVE-2026-53005CVE-2026-53009CVE-2026-53024CVE-2026-53025CVE-2026-53053CVE-2026-52941CVE-2026-53078CVE-2026-53070CVE-2026-53089CVE-2026-53090CVE-2026-53091CVE-2026-53109CVE-2026-53118CVE-2026-52934CVE-2026-53129CVE-2026-53120CVE-2026-53131CVE-2026-53132CVE-2026-53133CVE-2026-53148CVE-2026-53221CVE-2026-53217CVE-2026-53230CVE-2026-53216CVE-2026-53198CVE-2026-53196CVE-2026-53232CVE-2026-53186CVE-2026-53185CVE-2026-53183CVE-2026-53239CVE-2026-53182CVE-2026-52926CVE-2026-52922CVE-2026-52921CVE-2026-53275CVE-2026-53262CVE-2026-53264CVE-2026-53266CVE-2026-53256CVE-2026-53270CVE-2026-53281CVE-2026-53269CVE-2026-53250CVE-2026-53254CVE-2026-53273CVE-2026-52919CVE-2026-52918CVE-2026-52916CVE-2026-52915、 、 、 、 CVE-2026-63906CVE-2026-63795CVE-2026-53399CVE-2026-63797CVE-2026-63796CVE-2026-63800CVE-2026-63801CVE-2026-63804CVE-2026-63807CVE-2026-63808CVE-2026-53398CVE-2026-63818CVE-2026-63815CVE-2026-63825CVE-2026-63828CVE-2026-63829CVE-2026-63830CVE-2026-63831CVE-2026-53384CVE-2026-63858CVE-2026-63853CVE-2026-63886CVE-2026-63887CVE-2026-63888CVE-2026-63893CVE-2026-63924CVE-2026-63922CVE-2026-63926CVE-2026-63921CVE-2026-63919CVE-2026-63917CVE-2026-63940CVE-2026-63916CVE-2026-63915CVE-2026-63914CVE-2026-63944CVE-2026-63912CVE-2026-53368CVE-2026-53361CVE-2026-53358CVE-2026-63979CVE-2026-63948CVE-2026-63952CVE-2026-63974CVE-2026-63947CVE-2026-63976CVE-2026-63980CVE-2026-63975CVE-2026-63945CVE-2026-63946CVE-2026-63978CVE-2026-53357CVE-2026-53355CVE-2026-53354CVE-2026-53284、 、 、 、 CVE-2026-64087CVE-2026-64025CVE-2026-64018CVE-2026-64032CVE-2026-64029CVE-2026-64033CVE-2026-64034CVE-2026-64039CVE-2026-64046CVE-2026-64047CVE-2026-64015CVE-2026-64051CVE-2026-64048CVE-2026-64055CVE-2026-64056CVE-2026-64064CVE-2026-64073CVE-2026-64076CVE-2026-64011CVE-2026-64082CVE-2026-64077CVE-2026-64083CVE-2026-64084CVE-2026-64085CVE-2026-64086CVE-2026-64099CVE-2026-64098CVE-2026-64102CVE-2026-64097CVE-2026-64096CVE-2026-64093CVE-2026-64103CVE-2026-64092CVE-2026-64091CVE-2026-64089CVE-2026-64106CVE-2026-64088CVE-2026-64010CVE-2026-64007CVE-2026-64000CVE-2026-64118CVE-2026-64112CVE-2026-64113CVE-2026-64114CVE-2026-64111CVE-2026-64116CVE-2026-64121CVE-2026-64115CVE-2026-64108CVE-2026-64109CVE-2026-64117CVE-2026-63994CVE-2026-63993CVE-2026-63992CVE-2026-63984、 、 、 、 CVE-2026-64191CVE-2026-64144CVE-2026-64138CVE-2026-64148CVE-2026-64147CVE-2026-64153CVE-2026-64155CVE-2026-64160CVE-2026-64163CVE-2026-64165CVE-2026-64137CVE-2026-64168CVE-2026-64166CVE-2026-64170CVE-2026-64173CVE-2026-64174CVE-2026-64177CVE-2026-64178CVE-2026-64136CVE-2026-64180CVE-2026-64179CVE-2026-64182CVE-2026-64183CVE-2026-64184CVE-2026-64185CVE-2026-64231CVE-2026-64225CVE-2026-64237CVE-2026-64221CVE-2026-64220CVE-2026-64219CVE-2026-64247CVE-2026-64218CVE-2026-64217CVE-2026-64214CVE-2026-64249CVE-2026-64206CVE-2026-64135CVE-2026-64134CVE-2026-64133CVE-2026-64361CVE-2026-64303CVE-2026-64313CVE-2026-64315CVE-2026-64280CVE-2026-64320CVE-2026-64364CVE-2026-64319CVE-2026-64268CVE-2026-64269CVE-2026-64355CVE-2026-64128CVE-2026-64127CVE-2026-64126CVE-2026-64125、 、 、 、 CVE-2026-64552CVE-2026-64394CVE-2026-64393CVE-2026-64397CVE-2026-64396CVE-2026-64399CVE-2026-64400CVE-2026-64408CVE-2026-64438CVE-2026-64441CVE-2026-64392CVE-2026-64450CVE-2026-64445CVE-2026-64475CVE-2026-64510CVE-2026-64518CVE-2026-64523CVE-2026-64529CVE-2026-64391CVE-2026-64534CVE-2026-64530CVE-2026-64535CVE-2026-64541CVE-2026-64548CVE-2026-64551CVE-2026-64598CVE-2026-64597CVE-2026-68082CVE-2026-64586CVE-2026-64564CVE-2026-64562CVE-2026-68083CVE-2026-64561CVE-2026-64557CVE-2026-64555CVE-2026-68117CVE-2026-64554CVE-2026-64390CVE-2026-64387CVE-2026-64386CVE-2026-68154CVE-2026-68136CVE-2026-68137CVE-2026-68138CVE-2026-68127CVE-2026-68147CVE-2026-68156CVE-2026-68144CVE-2026-68123CVE-2026-68124CVE-2026-68152CVE-2026-64385CVE-2026-64384CVE-2026-64383CVE-2026-64382、 、 、 、 CVE-2026-72083CVE-2026-68228CVE-2026-68213CVE-2026-68300CVE-2026-68229CVE-2026-68302CVE-2026-68343CVE-2026-68381CVE-2026-68388CVE-2026-68426CVE-2026-68210CVE-2026-68457CVE-2026-68431CVE-2026-68461CVE-2026-68470CVE-2026-68476CVE-2026-68477CVE-2026-72014CVE-2026-68209CVE-2026-72033CVE-2026-72020CVE-2026-72041CVE-2026-72065CVE-2026-72069CVE-2026-72071CVE-2026-72130CVE-2026-72129CVE-2026-72191CVE-2026-72126CVE-2026-72125CVE-2026-72124CVE-2026-72192CVE-2026-72111CVE-2026-72098CVE-2026-72085CVE-2026-72194CVE-2026-72084CVE-2026-68206CVE-2026-68198CVE-2026-68162CVE-2026-72289CVE-2026-72222CVE-2026-72226CVE-2026-72234CVE-2026-72221CVE-2026-72255CVE-2026-72296CVE-2026-72251CVE-2026-72200CVE-2026-72217CVE-2026-72288CVE-2026-68161CVE-2026-68160CVE-2026-68159CVE-2026-68158、 、 、 、 CVE-2026-72499CVE-2026-72351CVE-2026-72348CVE-2026-72383CVE-2026-72380CVE-2026-72398CVE-2026-72399CVE-2026-72421CVE-2026-72422CVE-2026-72434CVE-2026-72339CVE-2026-72451CVE-2026-72436CVE-2026-72454CVE-2026-72466CVE-2026-72472CVE-2026-72473CVE-2026-72487CVE-2026-72329CVE-2026-72489CVE-2026-72488CVE-2026-72491CVE-2026-72494CVE-2026-72495CVE-2026-72496CVE-2026-74302CVE-2026-74287CVE-2026-74305CVE-2026-74280CVE-2026-74279CVE-2026-74269CVE-2026-74310CVE-2026-74268CVE-2026-74267CVE-2026-74264CVE-2026-74345CVE-2026-74255CVE-2026-72323CVE-2026-72322CVE-2026-72320CVE-2026-74408CVE-2026-74394CVE-2026-74398CVE-2026-74401CVE-2026-74384CVE-2026-74406CVE-2026-74410CVE-2026-74405CVE-2026-74350CVE-2026-74376CVE-2026-74407CVE-2026-72319CVE-2026-72318CVE-2026-72317CVE-2026-72299、 、 、 CVE-2026-74495CVE-2026-74474CVE-2026-74473CVE-2026-74439CVE-2026-74556CVE-2026-74493CVE-2026-74541CVE-2026-74476CVE-2026-74478CVE-2026-74480CVE-2026-74538CVE-2026-74569CVE-2026-74440CVE-2026-74521CVE-2026-74436CVE-2026-74475CVE-2026-74427CVE-2026-74417CVE-2026-74411

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

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

AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1792445930 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). (CVE-2024-57793)

  - 已解決 Linux 核心中的下列弱點：crypto: af_alg - zero initialize memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures. A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data. (CVE-2025-71113)

  - 已解決 Linux 核心中的下列弱點：rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example (CVE-2026-31630)

  - 已解決 Linux 核心中的下列弱點：netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - 已解決 Linux 核心中的下列弱點：drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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

CentOS Linux 6 主機安裝的套件會受到 TuxCare CENTOS6：CLSA-2026：1791949745 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. (CVE-2024-50302)

  - 已解決 Linux 核心中的下列弱點：ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. (CVE-2024-53197)

  - 已解決 Linux 核心中的下列弱點：smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key. (CVE-2026-46243)

  - 已解決 Linux 核心中的下列弱點：Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket. (CVE-2026-52918)

  - 已解決 Linux 核心中的下列弱點：netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). (CVE-2026-53266)

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

CentOS Linux 8.5 主機已安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1792979985 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：net: bridge: fix vlan tunnel dst refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm:
    ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP:
    0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08:
    0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge]
    __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
    __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2
    __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow (CVE-2021-47222)

  - 已解決 Linux 核心中的下列弱點：net: bridge: fix vlan tunnel dst null pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking.
    Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked in the egress path. (CVE-2021-47223)

  - 已解決 Linux 核心中的下列弱點：bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset.
    The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904 (CVE-2023-52676)

  - 已解決 Linux 核心中的下列弱點：cifs: fix session state check in reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

  - 已解決 Linux 核心中的下列弱點：ubi: Fix use-after-free when volume resizing failed There is an use-after-free problem reported by KASAN:
    ================================================================== BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2 PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi] ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record() returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume resizing. (CVE-2023-53800)

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

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - sctp：在 cookie 解壓縮後新增 INIT 驗證 在 SCTP 交握中，INIT 區塊最初由伺服器處理並嵌入到 INIT-ACK 中攜帶的 cookie 中。然後，用戶端透過 COOKIE-ECHO 傳回此 cookie，伺服器在其中解壓縮並重建原始 INIT 區塊。啟用 Cookie 驗證後，Cookie 內容會受到保護，防止竄改，因此重複使用解壓縮的 INIT 而不重新驗證是安全的。但是，當停用 cookie 驗證時，重建的 INIT 就無法再受信任。在此情況下，必須在解壓縮之後明確驗證 INIT，以避免處理可能遭竄改的資料。停用 sctp_verify_init（） 時，在 COOKIE-ECHO 處理路徑 （sctp_sf_do_5_1D_ce（） 和 sctp_sf_do_5_2_4_dupcook（）） 中解壓縮 cookie 後新增 cookie_auth_enable（） 檢查。失敗時，會釋放新的關聯，並捨棄封包。此外，在將內嵌區塊類型視為 INIT 區塊之前，先驗證內嵌區塊類型是否SCTP_CID_INIT，以加強 sctp_unpack_cookie（） 中的 cookie 驗證。最後，更新 sctp_verify_init（） 以使用實際嵌入的 INIT 長度而不是區塊>chunk_end來驗證參數邊界，因為儲存在 COOKIE-ECHO 中的 INIT 可能不會跨越整個區塊緩衝區。（CVE-2026-72398）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

遠端主機上安裝的核心版本早於 5.10.268-266.1092。因此，會受到 ALAS2KERNEL-5.10-2026-132 公告中所提及的多個弱點影響。

    在 Linux 核心中，下列弱點已解決：

    drm/virtio：對平面更新使用不中斷的 resv 鎖定 （CVE-2026-64098）

    在 Linux 核心中，下列弱點已解決：

    bpf：如果 BPF LSM 未初始化，則拒絕BPF_MAP_TYPE_INODE_STORAGE建立

    當設定 CONFIG_BPF_LSM=y 時，BPF inode 儲存體映射 （BPF_MAP_TYPE_INODE_STORAGE） 會編譯到核心中。但是，如果在啟動時未明確啟用 BPF LSM（例如，從 lsm= 啟動參數中省略），則永遠不會針對 BPF LSM 執行 lsm_prepare（）。

    因此，BPF inode 安全性 blob 位移 （bpf_lsm_blob_sizes.lbs_inode） 永遠不會初始化，並保持其預設編譯大小 8 位元組，而不是更新為超過保留結構rcu_head的有效位移 （通常為 16 位元組或更多）。

    當特權使用者建立並更新BPF_MAP_TYPE_INODE_STORAGEmap時，bpf_inode（） 會評估 inode->i_security + 8。這會錯誤地將 inode >i_security blob 開頭的結構 rcu_head.func 回呼指標別名。在後續的對應元素清除或 inode 損毀期間，將 NULL 寫入 owner_storage 會清除 queuedRCU 回呼指標。當 rcu_do_batch（） 稍後執行佇列回呼時，它會嘗試在位址0x0處擷取指令，從而觸發立即核心錯誤。

    透過引入標有 __ro_after_init 的全域 bpf_lsm_initialized 布林標記來解決此問題。當 LSM 架構成功註冊 BPF LSM 時，在 bpf_lsm_init（） 內將此標誌設定為 true。在此標誌的 inode_storage_map_alloc（） 中進行閘對應分配，如果 BPF LSM 反過來未初始化，則返回 EOPNOTSUPP。

    這種故障快速方法可防止使用者空間在支援的 BPF LSM 基礎架構缺失時配置 inode 儲存映射，從而避免殭屍映射狀態。（CVE-2026-64192）

    在 Linux 核心中，下列弱點已解決：

    i2c： core：修正轉接器取消註冊爭用 （CVE-2026-64279）

    在 Linux 核心中，下列弱點已解決：

    libceph：修正 decode_lockers（）CVE-2026-68082 （） 中兩個不安全的裸解碼

    在 Linux 核心中，下列弱點已解決：

    audit：修正 audit_dupe_exe（） 中的遞迴鎖定鎖死 （CVE-2026-68096）

    在 Linux 核心中，下列弱點已解決：

    super：修正凍結區塊裝置上的緊急解凍鎖死 （CVE-2026-68132）

    在 Linux 核心中，下列弱點已解決：

    net： gro：修正齊清標記的 skb 的雙重彙總 （CVE-2026-68136）

    在 Linux 核心中，下列弱點已解決：

    ftrace：新增全域互斥以序列化 trace_parser 存取 （CVE-2026-68146）

    在 Linux 核心中，下列弱點已解決：

    libceph：將 pg_{temp，upmap，upmap_items} 長度綁定為 CEPH_PG_MAX_SIZE （CVE-2026-68159）

    在 Linux 核心中，下列弱點已解決：

    sctp：避免在 netns 拆卸期間auth_enable sysctl UAF （CVE-2026-68162）

    在 Linux 核心中，下列弱點已解決：

    drm/virtio：繫結的 EDID 區塊讀取到回應緩衝區 （CVE-2026-68255）

    在 Linux 核心中，下列弱點已解決：

    drm/dp/mst：修正邊帶回覆剖析器 （CVE-2026-68277） 中 2 位元組欄位的 OOB 讀取

    在 Linux 核心中，下列弱點已解決：

    drm/dp/mst：修正邊帶區塊累積中的緩衝區溢位 （CVE-2026-68278）

    在 Linux 核心中，下列弱點已解決：

    drm/dp/mst：修正遠端 DPCD/I2C 邊帶回覆剖析器中的 OOB 讀取 （CVE-2026-68279）

    在 Linux 核心中，下列弱點已解決：

    mmc：vub300：修正探查失敗時的釋放後使用 （CVE-2026-72073）

    在 Linux 核心中，下列弱點已解決：

    scsi： target：繫結的 PR-OUT TransportID 剖析至接收的緩衝區 （CVE-2026-72084）

    在 Linux 核心中，下列弱點已解決：

    scsi：lpfc：修正 lpfc_sli4_driver_resource_setup（）CVE-2026-72087 （） 中的記憶體洩漏

    在 Linux 核心中，下列弱點已解決：

    dm-verity：使錯誤計數器不可部分完成 （CVE-2026-72096）

    在 Linux 核心中，下列弱點已解決：

    dm-integrity：不要將 hash_offset 遞增兩次 （CVE-2026-72099）

    在 Linux 核心中，下列弱點已解決：

    jbd2：修正 jbd2_journal_initialize_fast_commit（） 中的整數反向溢位 （CVE-2026-72225）

    在 Linux 核心中，下列弱點已解決：

    selinux：避免 selinux_sctp_bind_connect（） 中的sk_socket取消參照 （CVE-2026-72242）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nft_set_pipapo：不要將錯誤的複製洩漏到未來的事務中 （CVE-2026-72252）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_conntrack_sip：在存取 skb_dst（） 之前先驗證它 （CVE-2026-72253）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_queue：當 NFQUEUE 持有假 dst （） 時，pin 橋接裝置 （CVE-2026-72255）

    在 Linux 核心中，下列弱點已解決：

    KVM：arm64：vgic：處理中斷關聯性變更與停用 LPI 之間的爭用 （CVE-2026-72288）

    在 Linux 核心中，下列弱點已解決：

    TIPC：限制佇列追蹤點中的通訊端佇列傾出 （CVE-2026-72299）

    在 Linux 核心中，下列弱點已解決：

    mlxsw：修正 mlxsw_sp_port_lag_join（）CVE-2026-72308 （） 中的參照計數洩漏

    在 Linux 核心中，下列弱點已解決：

    sctp：在 cookie 解壓縮後新增 INIT 驗證 （CVE-2026-72398）

    在 Linux 核心中，下列弱點已解決：

    sctp：修正 INIT 處理中的 err_chunk 記憶體洩漏 （CVE-2026-72413）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nft_compat：ebtables 模擬必須拒絕非橋接目標 （CVE-2026-72416）

    在 Linux 核心中，下列弱點已解決：

    xprtrdma：重新張貼格式錯誤回覆的接收緩衝區 （CVE-2026-72464）

    在 Linux 核心中，下列弱點已解決：

    RDMA/rxe：修正 get_srq_wqe 中的 TOCTOU 堆積溢位 （CVE-2026-74378）

    在 Linux 核心中，下列弱點已解決：

    OPP：修正 OPP 新增和查詢 （） 之間的爭用 （CVE-2026-74405）

    在 Linux 核心中，下列弱點已解決：

    scsi： scsi_debug：修正 REPORT ZONES alloc_len下溢 OOB 寫入 （CVE-2026-74470）

    在 Linux 核心中，下列弱點已解決：

    net： pktgen：修正 proc 項目釋放後使用 （CVE-2026-74479）

    在 Linux 核心中，下列弱點已解決：

    binfmt_misc：移除項目時還原寫入存取權 （CVE-2026-74487）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_tables：使每個表nft_object rhltable （CVE-2026-74565）

    在 Linux 核心中，下列弱點已解決：

    封包：在非環形傳送路徑中使用一致的hard_header_len （CVE-2026-74582）

    在 Linux 核心中，下列弱點已解決：

    sched/psi：關閉 psi_cgroup_free（） 中的 rtpoll_timer （CVE-2026-74594）

    在 Linux 核心中，下列弱點已解決：

    ring-buffer：使用 current_context 進行安全的 per-CPU 緩衝區交換 （CVE-2026-74601）

    在 Linux 核心中，下列弱點已解決：

    net/sched：act_gact，act_police：範圍檢查後援控制動作 （CVE-2026-74620）

    在 Linux 核心中，下列弱點已解決：

    mm/huge_memory：修正huge_zero_pfn爭用 （CVE-2026-74632）

    在 Linux 核心中，下列弱點已解決：

    perf/core： 修正同級分離後的群組領導者釋放後使用 （CVE-2026-74637）

    在 Linux 核心中，下列弱點已解決：

    ipv4：修正 RTA_VIA nexthop 的 fib_nlmsg_size（） （CVE-2026-74657）

    在 Linux 核心中，下列弱點已解決：

    inet： frags：在布防計時器之前發布佇列 （CVE-2026-74662）

    在 Linux 核心中，下列弱點已解決：

    net/sched：拒絕過深的 qdisc 階層 （CVE-2026-74663）

    在 Linux 核心中，下列弱點已解決：

    packet：將壓力清除與環形重新配置同步 （CVE-2026-74666）

    在 Linux 核心中，下列弱點已解決：

    封包：在TX_RING傳送路徑中使用一致的hard_header_len （CVE-2026-74668）

    在 Linux 核心中，下列弱點已解決：

    net： tap：在剖析 tap_get_user_xdp（） 中的 virtio net 標頭之前設定 skb->dev （CVE-2026-74684）

    在 Linux 核心中，下列弱點已解決：

    net/sched： cls_api：破壞鎖定的分類器時，一律獲取 rtnl_lock （CVE-2026-74700）

    在 Linux 核心中，下列弱點已解決：

    netfilter： flowtable：最後發布 GC 可見元組 （CVE-2026-74746）

    在 Linux 核心中，下列弱點已解決：

    netfilter： ipset：修正 list：set GC 和 swap （CVE-2026-74748） 之間的參照計數爭用

    在 Linux 核心中，下列弱點已解決：

    ceph：修正懸置的 __ceph_get_caps（） 與過時mds_wanted （CVE-2026-80527）

    在 Linux 核心中，下列弱點已解決：

    ceph：使用 current->journal_info （CVE-2026-80528） 時避免 fs 回收

    在 Linux 核心中，下列弱點已解決：

    xfs：修正 xfs_dq_get_next_id （CVE-2026-80534） 中錯誤時的 ilock 洩漏

    在 Linux 核心中，下列弱點已解決：

    xfs：邊界檢查緩衝區記錄項目的已變更點陣圖 （CVE-2026-80536）

    在 Linux 核心中，下列弱點已解決：

    libceph：透過缺少邊界檢查 （CVE-2026-80557） 修正 decode_watchers（） 中的 OOB 讀取

    在 Linux 核心中，下列弱點已解決：

    libceph：避免使用 primary_temp （CVE-2026-80558） 中無效的 osd 索引

    在 Linux 核心中，下列弱點已解決：

    libceph：修正 decode_locker（） 中的多個不安全解碼 （CVE-2026-80561）

    在 Linux 核心中，下列弱點已解決：

    mptcp： options：在大小意外的情況下重設 DSS 欄位 （CVE-2026-80586）

    在 Linux 核心中，下列弱點已解決：

    inet： frags：在重組之前從片段中剝離 GSO 狀態 （CVE-2026-80590）

    在 Linux 核心中，下列弱點已解決：

    serial： amba-pl011： synchronize DMA teardown （CVE-2026-80737）

    在 Linux 核心中，下列弱點已解決：

    af_packet：不要在 tpacket_snd（） 中傳送零位元組資料。（CVE-2026-80742）

    在 Linux 核心中，下列弱點已解決：

    netfilter： nf_tables_offload：禁止中止路徑中 ENOMEM 的WARN_ON_ONCE （CVE-2026-80744）

    在 Linux 核心中，下列弱點已解決：

    selinux：不要取消從未開始的原則轉換 （CVE-2026-80756）

    在 Linux 核心中，下列弱點已解決：

    selinux：拒絕低於其繼承的 common （CVE-2026-80757） 的類別權限計數

    在 Linux 核心中，下列弱點已解決：

    HID： hyperv：驗證初始裝置資訊邊界 （CVE-2026-80765）

    在 Linux 核心中，下列弱點已解決：

    HID： core：修正 hid_set_field（） 中 field->usage 的 OOB 讀取 （CVE-2026-80781）

    在 Linux 核心中，下列弱點已解決：

    ipv6：修正 ip6_finish_output2（） 中的釋放後使用 （CVE-2026-80792）

    在 Linux 核心中，下列弱點已解決：

    ipv4：拒絕 ip_do_fragment（） 中大小過小的 MTU （CVE-2026-80793）

    在 Linux 核心中，下列弱點已解決：

    xfs：在欄位存取之前驗證 ATTR 進入指標 （CVE-2026-80805）

    在 Linux 核心中，下列弱點已解決：

    ext4：停止重試飽和的 xattr 快取項目 （CVE-2026-80808）

    在 Linux 核心中，下列弱點已解決：

    rndis_host：在 rndis_rx_fixup（） 中新增溢位檢查 （CVE-2026-80814）

    在 Linux 核心中，下列弱點已解決：

    net： packet：修正傳送 VLAN 標記框架時的錯誤transport_header （CVE-2026-80906）

    在 Linux 核心中，下列弱點已解決：

    selinux：要求定義每個布林值 （CVE-2026-80913）

    在 Linux 核心中，下列弱點已解決：

    HID： core：修正長項目上的數字/指標類型混淆 （CVE-2026-80918）

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

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

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

    - ARM64 架構;

    - S390 架構;

    - x86 架構；

    - DRBD 分散式複制區塊裝置驅動程式；

    - InfiniBand 驅動程式；

    - IOMMU 子系統；

    - 多個裝置驅動程式；

    - 網路驅動程式；

    - Microsoft Azure 網路介面卡 (MANA) 驅動程式；

    - NVME 驅動程式；

    - TCM 子系統；

    - Virtio Host (VHOST) 子系統;

    - Xen Hypervisor 驅動程式；

    - AFS 檔案系統；

    - 檔案系統基礎架構；

    - 網路檔案系統程式庫；

    - 網路檔案系統 (NFS) 用戶端；

    - NTFS3 檔案系統；

    - OCFS2 檔案系統；

    - OrangeFS 檔案系統；

    - SMB 網路檔案系統；

    - IPv4 網路；

    - Sun RPC 通訊協定；

    - IPv6 網路；

    - IP 通道定義；

    - Netfilter；

    - TCP 網路通訊協定；

    - 鎖定基元 ;

    - 9P 檔案系統網路通訊協定；

    - B.A.T.M.A.N. 網狀通訊協定；

    - 網路核心；

    - IFE 協議;

    - RxRPC 工作階段通訊端；

    - 網路流量控制 ;

    - SCTP 通訊協定；

    - SMC 通訊端;

    - TIPC 通訊協定;

    - XFRM 子系統;（CVE-2026-64530 ， ， ， CVE-2026-64535， CVE-2026-64541CVE-2026-72277CVE-2026-72137CVE-2026-72139CVE-2026-72064CVE-2026-72065CVE-2026-72046CVE-2026-72083CVE-2026-72069CVE-2026-72084CVE-2026-72085CVE-2026-72098CVE-2026-72129CVE-2026-72130CVE-2026-72041CVE-2026-72192CVE-2026-72191CVE-2026-72194CVE-2026-72217CVE-2026-72220CVE-2026-72221CVE-2026-72222CVE-2026-72033CVE-2026-72234CVE-2026-72226CVE-2026-72248CVE-2026-72249CVE-2026-72251CVE-2026-72278CVE-2026-72279CVE-2026-72020CVE-2026-72288CVE-2026-72287CVE-2026-72323CVE-2026-72322CVE-2026-72329CVE-2026-72320CVE-2026-72319CVE-2026-72318CVE-2026-72339CVE-2026-72317CVE-2026-72299CVE-2026-72296CVE-2026-72348CVE-2026-72289CVE-2026-72014CVE-2026-72351CVE-2026-72393CVE-2026-72381CVE-2026-72398CVE-2026-72366CVE-2026-72399CVE-2026-72412CVE-2026-64551CVE-2026-68457CVE-2026-72417CVE-2026-68083CVE-2026-68476CVE-2026-68477CVE-2026-72355CVE-2026-64534CVE-2026-72422， CVE-2026-72429CVE-2026-72436CVE-2026-72442CVE-2026-72451CVE-2026-72463CVE-2026-72466CVE-2026-72472CVE-2026-72473CVE-2026-72477CVE-2026-72491CVE-2026-72493CVE-2026-72494CVE-2026-72495CVE-2026-72496CVE-2026-72501CVE-2026-74255CVE-2026-74267CVE-2026-74268CVE-2026-74269CVE-2026-74287CVE-2026-74310CVE-2026-74345CVE-2026-74350CVE-2026-74361CVE-2026-74376CVE-2026-74384CVE-2026-74394CVE-2026-74398CVE-2026-74401CVE-2026-74406CVE-2026-74427CVE-2026-74428CVE-2026-74433CVE-2026-74434CVE-2026-74436CVE-2026-74439CVE-2026-80665

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
345814	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2026-2143)	Nessus	Amazon Linux Local Security Checks	2026/9/14	2026/9/25	medium
374135	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc多個弱點（ALMALINUX9.2：CLSA-2026：1793333110）	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
369491	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個漏洞（ALMALINUX9.6：CLSA-2026：1792445930）	Nessus	Rocky Linux Local Security Checks	2026/10/21	2026/10/21	high
348386	Ubuntu 24.04 LTS / Pro 即時 24.04 LTS：Linux 核心（NVIDIA Tegra）弱點（USN-8781-1）	Nessus	Ubuntu Local Security Checks	2026/9/21	2026/9/21	high
369490	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1792445930）	Nessus	Alma Linux Local Security Checks	2026/10/21	2026/10/21	high
367921	CentOS Linux 6 [TuxCare] 安全性更新：核心 / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc 多個弱點（CENTOS6：CLSA-2026：1791949745）	Nessus	CentOS Local Security Checks	2026/10/20	2026/10/22	high
371988	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點（CENTOS8.5：CLSA-2026：1792979985）	Nessus	CentOS Local Security Checks	2026/10/26	2026/11/2	high
335529	Linux Distros 未修補弱點：CVE-2026-72398	Nessus	Misc.	2026/8/15	2026/11/7	critical
365768	Ubuntu 26.04 LTS：Linux 核心 (Azure) 弱點 (USN-8888-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
351061	Amazon Linux 2：kernel (ALASKERNEL-5.10-2026-132)	Nessus	Amazon Linux Local Security Checks	2026/9/29	2026/10/26	medium
341880	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-2071)	Nessus	Amazon Linux Local Security Checks	2026/8/31	2026/9/15	high
350177	Ubuntu 24.04 LTS/26.04 LTS：Linux 核心弱點 (USN-8816-1)	Nessus	Ubuntu Local Security Checks	2026/9/25	2026/9/30	critical

偵測

搜尋 Plugin

medium

high

high

high

high

high

high

critical

medium

medium

high

critical