CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：1792247642公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：ethtool: do not perform operations on net devices being unregistered There is a short period between a net device starts to be unregistered and when it is actually gone. In that time frame ethtool operations could still be performed, which might end up in unwanted or undefined behaviours[1]. Do not allow ethtool operations after a net device starts its unregistration. This patch targets the netlink part as the ioctl one isn't affected: the reference to the net device is taken and the operation is executed within an rtnl lock section and the net device won't be found after unregister. [1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace:
    dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610 (CVE-2021-47517)

  - 已修复 Linux 内核中的下列漏洞：nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.
    (CVE-2022-48686)

  - 已修复 Linux 内核中的下列漏洞：net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator.
    NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c (bonding: fix 802.3ad aggregator reselection) ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148]
    __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 (CVE-2022-49667)

  - 已修复 Linux 内核中的下列漏洞：bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32
    *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18:
    w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. (CVE-2022-49961)

  - 在 Linux 内核的 SCSI 子组件中，发现 drivers/scsi/iscsi_tcp.c 的 iscsi_sw_tcp_session_create 存在释放后使用漏洞。攻击者可利用此缺陷泄露内核内部信息。
    (CVE-2023-2162)

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

CentOS Linux 8 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS-STREAM8：CLSA-2026：1792759740公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：mrp: introduce active flags to prevent UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no this synchronization, there is a small probability that the cancellation will not be successful. And syzbot report the fellowing crash: ================================================================== BUG:
    KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256 Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not restart. (CVE-2022-50697)

  - 已修复 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)

  - 已修复 Linux 内核中的下列漏洞：RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
    (CVE-2026-45856)

  - 已修复 Linux 内核中的下列漏洞：gfs2: Fix slab-use-after-free in qd_put Commit a475c5dd16e5 (gfs2: Free quota data objects synchronously) started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey <kartikey406@gmail.com>. (CVE-2026-45861)

  - 已修复 Linux 内核中的下列漏洞：gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2.
    Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] (CVE-2026-45984)

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

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

  - 已修复 Linux 内核中的下列漏洞：scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable. (CVE-2025-37861)

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - 已修复 Linux 内核中的下列漏洞：ASoC: Intel: avs: Disable periods-elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - 已修复 Linux 内核中的下列漏洞：ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

CentOS Linux 8.4 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.4：CLSA-2026：2026：1792243729公告中提及的多个漏洞的影响。

  - 在 Linux 内核 5.14.15 之前的版本中发现问题。drivers/isdn/capi/kcapi.c 的 detach_capi_ctr 函数中存在 array-index-out-of-bounds 缺陷。(CVE-2021-43389)

  - 已修复 Linux 内核中的下列漏洞：isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, kcmtpd_ctr_%d, session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ?
    __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] (CVE-2021-4439)

  - 已修复 Linux 内核中的下列漏洞：Drivers: hv: vmbus: Use after free in
    __vmbus_open() The open_info variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees open_info without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. (CVE-2021-47049)

  - 已修复 Linux 内核中的下列漏洞：scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. (CVE-2021-47565)

  - 已修复 Linux 内核中的下列漏洞：igbvf: fix double free in `igbvf_probe` In `igbvf_probe`, if register_netdev() fails, the program will go to label err_hw_init, and then to label err_ioremap. In free_netdev() which is just below label err_ioremap, there is `list_for_each_entry_safe` and `netif_napi_del` which aims to delete all entries in `dev->napi_list`. The program has added an entry `adapter->rx_ring->napi` which is added by `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has been freed below label err_hw_init. So this a UAF. In terms of how to patch the problem, we can refer to igbvf_remove() and delete the entry before `adapter->rx_ring`. The KASAN logs are as follows: [ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450 [ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366 [35.128360] [ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [35.131749] Call Trace: [ 35.132199] dump_stack_lvl+0x59/0x7b [ 35.132865] print_address_description+0x7c/0x3b0 [ 35.133707] ? free_netdev+0x1fd/0x450 [ 35.134378]
    __kasan_report+0x160/0x1c0 [ 35.135063] ? free_netdev+0x1fd/0x450 [ 35.135738] kasan_report+0x4b/0x70 [35.136367] free_netdev+0x1fd/0x450 [ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf] [ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf] [ 35.138751] local_pci_probe+0x13c/0x1f0 [ 35.139461] pci_device_probe+0x37e/0x6c0 [ 35.165526] [ 35.165806] Allocated by task 366: [ 35.166414]
    ____kasan_kmalloc+0xc4/0xf0 [ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf] [ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf] [ 35.168866] local_pci_probe+0x13c/0x1f0 [ 35.169565] pci_device_probe+0x37e/0x6c0 [ 35.179713] [ 35.179993] Freed by task 366: [ 35.180539] kasan_set_track+0x4c/0x80 [ 35.181211] kasan_set_free_info+0x1f/0x40 [ 35.181942]
    ____kasan_slab_free+0x103/0x140 [ 35.182703] kfree+0xe3/0x250 [ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf] [ 35.184040] local_pci_probe+0x13c/0x1f0 (CVE-2021-47589)

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

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

  - wifi：mt76：mt76x02：不警告无效的 rx 描述符长度 rx 描述符中的 MPDU 长度来自硬件。在启用了 fcsfail 过滤器的监控模式下，硬件会传递损坏的帧，损坏的帧可报告长度大于接收到的缓冲区。边界检查正确地丢弃此类帧，但其WARN_ON_ONCE封装程序意味着任何无线垃圾帧都会污染内核，并在设置panic_on_warn时在第一个此类帧上使其发生错误。终止 WARN 并静默丢弃帧，与提交 c2d4c8723dbf（mt76x2：删除 tx 状态和 rx 路径中的某些无害WARN_ONs）对相邻 rx 和 tx 状态路径执行的操作相匹配。当忙通道上的 fcsfail 监控模式下MT7612U时，在 rx 上立即观察到。（CVE-2026-90382）

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

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

  - 已修复 Linux 内核中的下列漏洞：ethernet: hisilicon: hns:
    hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
    because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns. (CVE-2021-47548)

  - 已修复 Linux 内核中的下列漏洞：SUNRPC: Fix a suspicious RCU usage warning I received the following warning while running cthon against an ontap server running pNFS: [57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
    __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
    __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
    __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
    0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
    00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated--- (CVE-2023-52623)

  - 已修复 Linux 内核中的下列漏洞：dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the hash_list entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the resume and postsuspend methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP:
    0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX:
    000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10:
    0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ?
    __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]--- (CVE-2024-26880)

  - 已修复 Linux 内核中的下列漏洞：netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e (netfilter: nf_tables: flush pending destroy work before netlink notifier) to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ?
    __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ?
    __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750]
    __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953]
    ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036]
    __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list
    *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list);
    11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat
    ---truncated--- (CVE-2024-35899)

  - 已修复 Linux 内核中的下列漏洞：drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. (CVE-2024-35950)

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

远程 Debian 12 主机上存在安装的程序包，该程序包受到 DLA-4841 公告中提及的多个漏洞的影响。

    - ------------------------------------------------------------------------- Debian LTS 公告 DLA-4841-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Salvatore Bonaccorso 2026 年 10 月 17 日 https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    程序包：linux 版本： 6.1.190-1 CVE ID： CVE-2023-52629 CVE-2023-52676 CVE-2023-53231 CVE-2023-53336 CVE-2023-53353 CVE-2023-53429 CVE-2023-53491 CVE-2023-53538 CVE-2023-53574 CVE-2023-53627 CVE-2023-53762 CVE-2023-53851 CVE-2023-53857 CVE-2023-53999 CVE-2023-54227 CVE-2023-54233 CVE-2024-35887 CVE-2024-49568 CVE-2024-50017 CVE-2024-50029 CVE-2024-58097 CVE-2025-21649 CVE-2025-21651 CVE-2025-21759 CVE-2025-22039 CVE-2025-22103 CVE-2025-23129 CVE-2025-37833 CVE-2025-40074 CVE-2025-40097 CVE-2025-68190 CVE-2025-68736 CVE-2026-23191 CVE-2026-23447 CVE-2026-23448 CVE-2026-31420 CVE-2026-43088 CVE-2026-43198 CVE-2026-43288 CVE-2026-45897 CVE-2026-46090 CVE-2026-52944 CVE-2026-52988 CVE-2026-53005 CVE-2026-53078 CVE-2026-64210 CVE-2026-68097 CVE-2026-68161 CVE-2026-68236 CVE-2026-68286 CVE-2026-68287 CVE-2026-68288 CVE-2026-68289 CVE-2026-68391 CVE-2026-72334 CVE-2026-72402 CVE-2026-72413 CVE-2026-74268 CVE-2026-74289 CVE-2026-74294 CVE-2026-74334 CVE-2026-74474 CVE-2026-74496 CVE-2026-74521 CVE-2026-74565 CVE-2026-80521 CVE-2026-80671 CVE-2026-80689 CVE-2026-80833 CVE-2026-80834 CVE-2026-80912 CVE-2026-80914 CVE-2026-80928 CVE-2026-80930 CVE-2026-80931 CVE-2026-80932 CVE-2026-80938 CVE-2026-80941 CVE-2026-80944 CVE-2026-80949 CVE-2026-80951 CVE-2026-80952 CVE-2026-80963 CVE-2026-80964 CVE-2026-80965 CVE-2026-80966 CVE-2026-80967 CVE-2026-80968 CVE-2026-80969 CVE-2026-80971 CVE-2026-80972 CVE-2026-80973 CVE-2026-80976 CVE-2026-80977 CVE-2026-80978 CVE-2026-80982 CVE-2026-80983 CVE-2026-80987 CVE-2026-80988 CVE-2026-80992 CVE-2026-80994 CVE-2026-81000 CVE-2026-81001 CVE-2026-81002 CVE-2026-81003 CVE-2026-81005 CVE-2026-81007 CVE-2026-81008 CVE-2026-81017 CVE-2026-89440 CVE-2026-89444 CVE-2026-89456 CVE-2026-89457 CVE-2026-89458 CVE-2026-89461 CVE-2026-89463 CVE-2026-89464 CVE-2026-89469 CVE-2026-89470 CVE-2026-89471 CVE-2026-89474 CVE-2026-89475 CVE-2026-89476 CVE-2026-89477 CVE-2026-89478 CVE-2026-89479 CVE-2026-89480 CVE-2026-89481 CVE-2026-89482 CVE-2026-89483 CVE-2026-89485 CVE-2026-89487 CVE-2026-89488 CVE-2026-89489 CVE-2026-89490 CVE-2026-89491 CVE-2026-89493 CVE-2026-89494 CVE-2026-89495 CVE-2026-89496 CVE-2026-89497 CVE-2026-89498 CVE-2026-89504 CVE-2026-89508 CVE-2026-89510 CVE-2026-89511 CVE-2026-89512 CVE-2026-89515 CVE-2026-89524 CVE-2026-89525 CVE-2026-89532 CVE-2026-89533 CVE-2026-89538 CVE-2026-89540 CVE-2026-89541 CVE-2026-89542 CVE-2026-89548 CVE-2026-89549 CVE-2026-89551 CVE-2026-89554 CVE-2026-89555 CVE-2026-89557 CVE-2026-89559 CVE-2026-89560 CVE-2026-89562 CVE-2026-89563 CVE-2026-89565 CVE-2026-89569 CVE-2026-89573 CVE-2026-89575 CVE-2026-89576 CVE-2026-89579 CVE-2026-89582 CVE-2026-89583 CVE-2026-89585 CVE-2026-89586 CVE-2026-89587 CVE-2026-89594 CVE-2026-89595 CVE-2026-89596 CVE-2026-89597 CVE-2026-89599 CVE-2026-89604 CVE-2026-89605 CVE-2026-89606 CVE-2026-89607 CVE-2026-89608 CVE-2026-89609 CVE-2026-89615 CVE-2026-89616 CVE-2026-89617 CVE-2026-89621 CVE-2026-89626 CVE-2026-89627 CVE-2026-89628 CVE-2026-89634 CVE-2026-89636 CVE-2026-89640 CVE-2026-89643 CVE-2026-89649 CVE-2026-89650 CVE-2026-89653 CVE-2026-89655 CVE-2026-89656 CVE-2026-89662 CVE-2026-89663 CVE-2026-89665 CVE-2026-89669 CVE-2026-89674 CVE-2026-89684 CVE-2026-89694 CVE-2026-89696 CVE-2026-89697 CVE-2026-89699 CVE-2026-89704 CVE-2026-89706 CVE-2026-89710 CVE-2026-89711 CVE-2026-89712 CVE-2026-89720 CVE-2026-89723 CVE-2026-89724 CVE-2026-89725 CVE-2026-89726 CVE-2026-89729 CVE-2026-89730 CVE-2026-89732 CVE-2026-89733 CVE-2026-89736 CVE-2026-89741 CVE-2026-89742 CVE-2026-89744 CVE-2026-89746 CVE-2026-89749 CVE-2026-89751 CVE-2026-89752 CVE-2026-89753 CVE-2026-89756 CVE-2026-89765 CVE-2026-89776 CVE-2026-89777 CVE-2026-89778 CVE-2026-89779 CVE-2026-89780 CVE-2026-89781 CVE-2026-89782 CVE-2026-89783 CVE-2026-89784 CVE-2026-89785 CVE-2026-89786 CVE-2026-89787 CVE-2026-89789 CVE-2026-89792 CVE-2026-89796 CVE-2026-89816 CVE-2026-89817 CVE-2026-89818 CVE-2026-89821 CVE-2026-89822 CVE-2026-89823 CVE-2026-89824 CVE-2026-89843 CVE-2026-89845 CVE-2026-89846 CVE-2026-89847 CVE-2026-89849 CVE-2026-89850 CVE-2026-89851 CVE-2026-89852 CVE-2026-89853 CVE-2026-89854 CVE-2026-89855 CVE-2026-89856 CVE-2026-89858 CVE-2026-89861 CVE-2026-89863 CVE-2026-89864 CVE-2026-89865 CVE-2026-89870 CVE-2026-89871 CVE-2026-89872 CVE-2026-89876 CVE-2026-89877 CVE-2026-89878 CVE-2026-89879 CVE-2026-89880 CVE-2026-89881 CVE-2026-89883 CVE-2026-89887 CVE-2026-89888 CVE-2026-89890 CVE-2026-89891 CVE-2026-89892 CVE-2026-89893 CVE-2026-89894 CVE-2026-89895 CVE-2026-89896 CVE-2026-89897 CVE-2026-89901 CVE-2026-89922 CVE-2026-89923 CVE-2026-89924 CVE-2026-89925 CVE-2026-89926 CVE-2026-89927 CVE-2026-89930 CVE-2026-89932 CVE-2026-89936 CVE-2026-89937 CVE-2026-89939 CVE-2026-89945 CVE-2026-89946 CVE-2026-89947 CVE-2026-89948 CVE-2026-89949 CVE-2026-89951 CVE-2026-89952 CVE-2026-89953 CVE-2026-89954 CVE-2026-89957 CVE-2026-89959 CVE-2026-89964 CVE-2026-89965 CVE-2026-89968 CVE-2026-89969 CVE-2026-89970 CVE-2026-89973 CVE-2026-89979 CVE-2026-89980 CVE-2026-89982 CVE-2026-89983 CVE-2026-89984 CVE-2026-89988 CVE-2026-89989 CVE-2026-89992 CVE-2026-89993 CVE-2026-89997 CVE-2026-89998 CVE-2026-89999 CVE-2026-90000 CVE-2026-90003 CVE-2026-90007 CVE-2026-90011 CVE-2026-90015 CVE-2026-90017 CVE-2026-90018 CVE-2026-90019 CVE-2026-90020 CVE-2026-90025 CVE-2026-90031 CVE-2026-90032 CVE-2026-90033 CVE-2026-90034 CVE-2026-90049 CVE-2026-90053 CVE-2026-90054 CVE-2026-90055 CVE-2026-90056 CVE-2026-90057 CVE-2026-90058 CVE-2026-90060 CVE-2026-90062 CVE-2026-90063 CVE-2026-90067 CVE-2026-90068 CVE-2026-90070 CVE-2026-90071 CVE-2026-90072 CVE-2026-90073 CVE-2026-90074 CVE-2026-90075 CVE-2026-90078 CVE-2026-90081 CVE-2026-90088 CVE-2026-90090 CVE-2026-90091 CVE-2026-90092 CVE-2026-90102 CVE-2026-90103 CVE-2026-90107 CVE-2026-90108 CVE-2026-90110 CVE-2026-90114 CVE-2026-90122 CVE-2026-90124 CVE-2026-90126 CVE-2026-90128 CVE-2026-90140 CVE-2026-90141 CVE-2026-90143 CVE-2026-90151 CVE-2026-90157 CVE-2026-90160 CVE-2026-90176 CVE-2026-90180 CVE-2026-90184 CVE-2026-90185 CVE-2026-90186 CVE-2026-90188 CVE-2026-90189 CVE-2026-90190 CVE-2026-90194 CVE-2026-90196 CVE-2026-90198 CVE-2026-90202 CVE-2026-90203 CVE-2026-90207 CVE-2026-90209 CVE-2026-90214 CVE-2026-90216 CVE-2026-90218 CVE-2026-90219 CVE-2026-90221 CVE-2026-90222 CVE-2026-90223 CVE-2026-90224 CVE-2026-90225 CVE-2026-90226 CVE-2026-90228 CVE-2026-90245 CVE-2026-90248 CVE-2026-90249 CVE-2026-90251 CVE-2026-90253 CVE-2026-90254 CVE-2026-90255 CVE-2026-90257 CVE-2026-90274 CVE-2026-90281 CVE-2026-90283 CVE-2026-90284 CVE-2026-90285 CVE-2026-90286 CVE-2026-90287 CVE-2026-90290 CVE-2026-90292 CVE-2026-90293 CVE-2026-90294 CVE-2026-90295 CVE-2026-90296 CVE-2026-90297 CVE-2026-90298 CVE-2026-90302 CVE-2026-90303 CVE-2026-90307 CVE-2026-90309 CVE-2026-90314 CVE-2026-90316 CVE-2026-90318 CVE-2026-90319 CVE-2026-90327 CVE-2026-90329 CVE-2026-90334 CVE-2026-90341 CVE-2026-90348 CVE-2026-90352 CVE-2026-90353 CVE-2026-90354 CVE-2026-90357 CVE-2026-90360 CVE-2026-90361 CVE-2026-90362 CVE-2026-90372 CVE-2026-90378 CVE-2026-90382 CVE-2026-90386 CVE-2026-90388 CVE-2026-90391 CVE-2026-90393 CVE-2026-90394 CVE-2026-90395 CVE-2026-90403 CVE-2026-90411 CVE-2026-90413 CVE-2026-90414 CVE-2026-90415 CVE-2026-90416 CVE-2026-90419 CVE-2026-90420 CVE-2026-90431 CVE-2026-90434 CVE-2026-90435 CVE-2026-92476 CVE-2026-92477 CVE-2026-92481 CVE-2026-92494 CVE-2026-92496 CVE-2026-92498 CVE-2026-92501 CVE-2026-92504 CVE-2026-92507 CVE-2026-92508 CVE-2026-92509 CVE-2026-92510 CVE-2026-92511 CVE-2026-92512 CVE-2026-92514 CVE-2026-92521 CVE-2026-92522 CVE-2026-92523 CVE-2026-92524 CVE-2026-92525 CVE-2026-93037 CVE-2026-93039 CVE-2026-93040 CVE-2026-93041 CVE-2026-93046 CVE-2026-93048 CVE-2026-93049 CVE-2026-93050 CVE-2026-93051 CVE-2026-93052 CVE-2026-93053 CVE-2026-93054 CVE-2026-93055 CVE-2026-93056 CVE-2026-93061 CVE-2026-93063 CVE-2026-93064 CVE-2026-93067 CVE-2026-93073 CVE-2026-93095 CVE-2026-93098 CVE-2026-93102 CVE-2026-93103 CVE-2026-93108 CVE-2026-93109 CVE-2026-93110 CVE-2026-93114 CVE-2026-93115 CVE-2026-93117 CVE-2026-93118 CVE-2026-93120 CVE-2026-93130 CVE-2026-93131 CVE-2026-93136 CVE-2026-93137 CVE-2026-93138 CVE-2026-93140 CVE-2026-93141 CVE-2026-93142 CVE-2026-93145 CVE-2026-93149 CVE-2026-93151 CVE-2026-93152 CVE-2026-93158 CVE-2026-93159 CVE-2026-93160 CVE-2026-93161 CVE-2026-93165 CVE-2026-93167 CVE-2026-93170 CVE-2026-93177 CVE-2026-93178 CVE-2026-93182 CVE-2026-93183 CVE-2026-93185 CVE-2026-93188 CVE-2026-93189 CVE-2026-93190 CVE-2026-93191 CVE-2026-93203 CVE-2026-93204 CVE-2026-93206 CVE-2026-93210 CVE-2026-93213 CVE-2026-93214 CVE-2026-93219 CVE-2026-93222 CVE-2026-93226 CVE-2026-93234 CVE-2026-93236 CVE-2026-93242 CVE-2026-93245 CVE-2026-93247 CVE-2026-93252 CVE-2026-93256 CVE-2026-93261 CVE-2026-93262 CVE-2026-93264 CVE-2026-93268 CVE-2026-93271 CVE-2026-93274 CVE-2026-93278 CVE-2026-93279 CVE-2026-93280 CVE-2026-93281 CVE-2026-93283 CVE-2026-93286 CVE-2026-93287 CVE-2026-93288 CVE-2026-93781 CVE-2026-93782 CVE-2026-93783 CVE-2026-93784 CVE-2026-93785 CVE-2026-93787 CVE-2026-93788 CVE-2026-93789 CVE-2026-93795 CVE-2026-93797 CVE-2026-93798 CVE-2026-93800 CVE-2026-93802 CVE-2026-93803 CVE-2026-93805 CVE-2026-93806 CVE-2026-93807 CVE-2026-93808 CVE-2026-93810 CVE-2026-93811 CVE-2026-93812 CVE-2026-93813 CVE-2026-93814 CVE-2026-93815 CVE-2026-93816 CVE-2026-93819 CVE-2026-93820 CVE-2026-93821 CVE-2026-93822 CVE-2026-93824 CVE-2026-93825 CVE-2026-93826 CVE-2026-93830 CVE-2026-97407 CVE-2026-97408 CVE-2026-97411 CVE-2026-97413 CVE-2026-97415 CVE-2026-97416 CVE-2026-97417 CVE-2026-97418 CVE-2026-97419 CVE-2026-97420 CVE-2026-97421 CVE-2026-97427 CVE-2026-97430 CVE-2026-97434 CVE-2026-97435 CVE-2026-97436 CVE-2026-97437 CVE-2026-97438 CVE-2026-97439 CVE-2026-97440 CVE-2026-97441 CVE-2026-97442 CVE-2026-97444 CVE-2026-97445 CVE-2026-97446 CVE-2026-97448 CVE-2026-97449 CVE-2026-97450 CVE-2026-97451 CVE-2026-97452 CVE-2026-97453 CVE-2026-97454 CVE-2026-97455 CVE-2026-97456 CVE-2026-97472 CVE-2026-97475 CVE-2026-97476 CVE-2026-97481 CVE-2026-97482 CVE-2026-97483 CVE-2026-97484 CVE-2026-97485 CVE-2026-97486 CVE-2026-97487 CVE-2026-97488 CVE-2026-97489 CVE-2026-97490 CVE-2026-97491 CVE-2026-97492 CVE-2026-97495 CVE-2026-97497 CVE-2026-97502 CVE-2026-97506 CVE-2026-97507 CVE-2026-97508 CVE-2026-97509 CVE-2026-97510 CVE-2026-97516 CVE-2026-97517 CVE-2026-97523 CVE-2026-97524 CVE-2026-97539 CVE-2026-97540 CVE-2026-97541 CVE-2026-97556 CVE-2026-97557 CVE-2026-97564 CVE-2026-97568 CVE-2026-97572 CVE-2026-97573 CVE-2026-97576 CVE-2026-97581 CVE-2026-97582 CVE-2026-97592 CVE-2026-97596 CVE-2026-97598 CVE-2026-97601 CVE-2026-97604 CVE-2026-97608 CVE-2026-97611 CVE-2026-97612 CVE-2026-97899 CVE-2026-97904 CVE-2026-97905 CVE-2026-97909 CVE-2026-97910 CVE-2026-97920 CVE-2026-97921 CVE-2026-97922 CVE-2026-97923 CVE-2026-97925 CVE-2026-97926 CVE-2026-97927 CVE-2026-97930 CVE-2026-97931 CVE-2026-97940 CVE-2026-97948 CVE-2026-97951 CVE-2026-97952 CVE-2026-97954 CVE-2026-97957 CVE-2026-97958 CVE-2026-97959 CVE-2026-97963 CVE-2026-97964 CVE-2026-97969 CVE-2026-97970 CVE-2026-97973 CVE-2026-97977 CVE-2026-97979 CVE-2026-97981 CVE-2026-97982 CVE-2026-97986 CVE-2026-97987 CVE-2026-97991 CVE-2026-97993 CVE-2026-97995 CVE-2026-97998 CVE-2026-98006 CVE-2026-98008 CVE-2026-98009 CVE-2026-98010 CVE-2026-98011 CVE-2026-98012 CVE-2026-98013 CVE-2026-98014 CVE-2026-98015 CVE-2026-98016 CVE-2026-98017 CVE-2026-98022 CVE-2026-98023 CVE-2026-98025 CVE-2026-98027 CVE-2026-98030 CVE-2026-98031 CVE-2026-98046 CVE-2026-98055 CVE-2026-98063 CVE-2026-98064 CVE-2026-98066 CVE-2026-98068 CVE-2026-98069 CVE-2026-98070 CVE-2026-98071 CVE-2026-98072 CVE-2026-98074 CVE-2026-98075 CVE-2026-98076 CVE-2026-98077 CVE-2026-98078 CVE-2026-98080 CVE-2026-98088 CVE-2026-98089 CVE-2026-98090 CVE-2026-98091 CVE-2026-98092 CVE-2026-98094 CVE-2026-98095 CVE-2026-98096 CVE-2026-98098 CVE-2026-98104 CVE-2026-98108 CVE-2026-98113 CVE-2026-98116 CVE-2026-98121 CVE-2026-98123 CVE-2026-98128 CVE-2026-98129 CVE-2026-98130 CVE-2026-98154 CVE-2026-98157 CVE-2026-98158 CVE-2026-98159 CVE-2026-98160 CVE-2026-98167 CVE-2026-98169 CVE-2026-98171 CVE-2026-98172 CVE-2026-98181 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187 CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191 CVE-2026-98194 CVE-2026-98195 CVE-2026-98196 CVE-2026-98197 CVE-2026-98199 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203 CVE-2026-98204 CVE-2026-98205 CVE-2026-98207 CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98213 CVE-2026-98217 CVE-2026-98221 CVE-2026-98227 CVE-2026-98233 CVE-2026-98234 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238 CVE-2026-98239 CVE-2026-98241 CVE-2026-98246 CVE-2026-98247 CVE-2026-98249 CVE-2026-98251 CVE-2026-98252 CVE-2026-98253 CVE-2026-98255 CVE-2026-98257 CVE-2026-98260 CVE-2026-98262 CVE-2026-98264 CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282 CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98298 CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302 CVE-2026-98303 CVE-2026-98306 CVE-2026-98308 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322 CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98328 CVE-2026-98331 CVE-2026-98339 CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344 CVE-2026-98345 CVE-2026-98347 CVE-2026-98348 CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354 CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360 CVE-2026-98362 CVE-2026-98363 CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370 CVE-2026-98374 CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381 CVE-2026-98383 CVE-2026-98388 CVE-2026-98398 CVE-2026-98402 CVE-2026-98404 CVE-2026-98406 CVE-2026-98407 CVE-2026-98410 CVE-2026-98413 CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421 CVE-2026-98422 CVE-2026-98423 CVE-2026-98426 CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432 CVE-2026-99999 CVE-2026-100070 CVE-2026-100071 CVE-2026-100075 CVE-2026-100078 Debian 缺陷：1108860

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于 Debian 12 bookworm，这些问题已在版本 6.1.190-1中修复。

    建议您升级 linux 程序包。

    如需了解 linux 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux

    有关 Debian LTS 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://wiki.debian.org/LTS

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

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

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

  - 已修复 Linux 内核中的下列漏洞：scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable. (CVE-2025-37861)

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - 已修复 Linux 内核中的下列漏洞：ASoC: Intel: avs: Disable periods-elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - 已修复 Linux 内核中的下列漏洞：ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
366854	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2026：1792247642）	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/17	high
371420	CentOS Linux 8 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS-STREAM8：CLSA-2026：1792759740）	Nessus	CentOS Local Security Checks	2026/10/23	2026/10/27	high
371428	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1792762308）	Nessus	Rocky Linux Local Security Checks	2026/10/23	2026/10/23	high
366779	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2026：1792243729）	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/17	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
362907	Debian dla-4817：ata-modules-6.12.107+deb12-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
347780	Linux Distros 未修补的漏洞：CVE-2026-90382	Nessus	Misc.	2026/9/18	2026/11/6	medium
366778	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug 等多个漏洞（ALMALINUX9.2：CLSA-2026：1792243434）	Nessus	Alma Linux Local Security Checks	2026/10/17	2026/10/27	medium
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 内核 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
366919	Debian dla-4841：ata-modules-6.1.0-53-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/17	2026/10/17	high
371426	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1792762308）	Nessus	Alma Linux Local Security Checks	2026/10/23	2026/10/23	high

检测

插件搜索

high

high

high

high

high

high

medium

medium

high

high

high