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

  - drm/stmltdc修复后期取消引用检查 在 ltdc_crtc_set_crc_source() 中指针检查之前在 container_of() 中取消引用 struct drm_crtc。这可导致内核错误。修复此 smatch 警告
    drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() 警告检查“crtc”前取消引用变量请参阅第 1119 行 (CVE-2023-53714)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: Release the label when replacing existing ct entry Cited commit doesn't release the label mapping when replacing existing ct entry which leads to following memleak report: unreferenced object 0xffff8881854cf280 (size 96): comm kworker/u48:74, pid 23093, jiffies 4296664564 (age 175.944s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000002722d368>] __kmalloc+0x4b/0x1c0 [<00000000cc44e18f>] mapping_add+0x6e8/0xc90 [mlx5_core] [<000000003ad942a7>] mlx5_get_label_mapping+0x66/0xe0 [mlx5_core] [<00000000266308ac>] mlx5_tc_ct_entry_create_mod_hdr+0x1c4/0xf50 [mlx5_core] [<000000009a768b4f>] mlx5_tc_ct_entry_add_rule+0x16f/0xaf0 [mlx5_core] [<00000000a178f3e5>] mlx5_tc_ct_block_flow_offload_add+0x10cb/0x1f90 [mlx5_core] [<000000007b46c496>] mlx5_tc_ct_block_flow_offload+0x14a/0x630 [mlx5_core] [<00000000a9a18ac5>] nf_flow_offload_tuple+0x1a3/0x390 [nf_flow_table] [<00000000d0881951>] flow_offload_work_handler+0x257/0xd30 [nf_flow_table] [<000000009e4935a4>] process_one_work+0x7c2/0x13e0 [<00000000f5cd36a7>] worker_thread+0x59d/0xec0 [<00000000baed1daf>] kthread+0x28f/0x330 [<0000000063d282a4>] ret_from_fork+0x1f/0x30 Fix the issue by correctly releasing the label mapping.
    (CVE-2023-53720)

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

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

  - mm/vmemmap/devdax修复了探测 devdax 设备提交 4917f55b4ef9 时的内核崩溃问题 (mm/sparse-vmemmap
    改善复合 devmap 的内存节省添加了对 devdax 设备使用经过优化的 vmmemap 的支持。但 vmemmap 映射的创建方式因架构而异。例如具有哈希转换的 powerpc 在 init_mm 页表中没有 vmemmap 映射而是它们由 vmemmap 优化代码使用的硬件页表中的bolttable 表条目 vmemmap 优化代码使用的 vmemmap_populate_compound_pages() 不识别这些特定于架构的映射。因此允许架构选择此功能。我选择了支持 HUGETLB_PAGE_OPTIMIZE_VMEMMAP 选项的架构因为也支持此功能。此修补程序修复了 ppc64 中的以下崩溃。缺陷无法处理 0xc00c000100400038 处写入的内核数据访问 错误指令地址0xc000000001269d90 Oops不良区域的内核访问sig11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules 中链接的CPU 7 PID: 1 Commswapper/0 未受感染 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a 硬件名称
    IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM、FW950.40 (VL950_099) hv:phypSeries NIP
    c000000001269d90 LRc0000000004c57d4 CTR0000000000000000 REGSc000000003632c30 TRAP: 0300 未感染 (6.3.0-rc5-150500.34-default+) MSR: 8000000000009033<SF,EE,ME,IR,DR,RI,LE> CR: 24842228 XER: 00000000 CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0 .... NIP [c000000001269d90]
    __init_single_page.isra.74+0x14/0x4c LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0 调用跟踪
    [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable) [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250 [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0 [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0 [c000000003633100] [c000000000d458a8] dev_dax_probe +0x108/0x3e0 [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140 [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520 [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120 [c000000003633320 ] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0 [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130 [c000000003633400] [c000000000ceefcc]
    __device_attach+0x15c/0x250 [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110 [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10 [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530 [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270 [ c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70 [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0 [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520 [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c000000003633970] [c000000000cef888] driver_probe_device +0x58/0x120 [c0000000036339b0] [c000000000cefd08]
    __driver_attach+0x1d8/0x240 [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130 [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50 [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300 [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0 [ c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100 [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48 [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320 [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400 [c000000003633de0] [c000000000013764] kernel_init +0x34/0x1d0 [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64 (CVE-2023-53706)

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

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

  - fs/ntfs3修复 ni_write_inode 中的空取消引用 Syzbot 报告 ni_write_inode 中存在空取消引用。创建新 inode 时如果 mi_init 函数在 mi_format_new 函数中调用导致分配失败mi->mrec 将设置为空。在此 inode 创建的错误路径中mi->mrec 之后在 ni_write_inode 中被取消引用。添加 NULL 检查以防止 NULL 取消引用。 (CVE-2023-53732)

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

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

  - 特制的委派或 IP 片段可毒化 Recursor 中缓存的委派。 (CVE-2025-59024)

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

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

  - 在处理 EXSLT 的 libxslt 的 exsltFuncResultComp() 函数中发现一个缺陷<func:result>在样式表解析期间读取元素。由于类型处理不当该函数可能将 XML 文档节点视为常规 XML 元素节点从而导致类型混淆。这可能会造成意外的内存读取和潜在的崩溃。该缺陷虽然难以利用但可导致应用程序不稳定或拒绝服务。 (CVE-2025-11731)

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

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

  - 可以更改本应不可写入的 JavaScript 对象属性的值。此漏洞会影响 Firefox < 144、Firefox ESR < 115.29、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11711)

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

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

  - octeontx2-pf修复 otx2_tc_add_flow() 中潜在的释放后使用 此代码调用 kfree_rcu(new_node, rcu) 然后取消引用 new_node然后在下一行取消引用它。两行后，我们采用互斥体，因此我认为这是不是 RCU 安全区域。重新排序使其在排队释放之前执行取消引用。 (CVE-2025-39978)

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

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

  - 蓝牙MGMT修复可能的 UAF此操作尝试修复可能的 UAF由结构 mgmt_pending 在仍在处理时被释放可能造成的 UAF如下跟踪中所示这是为了修复 mgmt_pending_valid 被引入和使用以检查 mgmt_pending 是否已从 移除待定列表在完整的回调中用于检查此外在保持 mgmt_pending_lock 时从列表中删除 cmd以避免 TOCTOU 问题因为如果 cmd 留在列表上仍然可访问和释放它。BUG：
    KASAN在 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 中在任务 kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm发生的对 addr ffff8880709d4dc0 上大小 8 的读取中存在 slab 使用后释放问题kworker/u11:0 未受感染 6.16.4 #2 PREEMPT(full) Hardware nameQEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueuehci0 hci_cmd_sync_work 调用追踪 <TASK> dump_stack_lvl+ 0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [内联] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c 595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17queue.b0c kernel/workqueue.b0c :3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii /source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 </TASK> 由任务分配 12210kasan_save_stack mm/kasan/common.c:47 [内联] kasan_save_track+0x3e/ 0x80 mm/kasan/common.c:68毒害_kmalloc_redzone mm/kasan/common.c:377 [内联] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [内联] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [内联] kzalloc_noprof include/linux/slab.h:1039 [内联] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c ! /bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [内联] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x3258/0x3258/0x3258 net/socket.c:1133 new_sync_wri te fs/read_write.c:593 [内联] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由任务释放 12221kasan_save_stack mm/kasan/common.c:47 [内联] kasan_save_track+0x3e/0x80 mm/kasan/common。 c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576毒害_slab_object mm/kasan/common.c:247 [内联] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan .h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c 311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257
    __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/ hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [内联] __do_sys_ioctl fs/ioctl.c:907 [内联] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf ---truncated--- (CVE-2025-39981)

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

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

  - nettun在 XDP 进程后更新 napi->skb syzbot 报告 UAF 问题BUG: KASAN: slab_reset_mac_header include/linux/skbuff.h:3150 [inline] BUGKASAN: slab napi_frags_skb net/core/gro.c:723 中的 -use-after-free [内联] BUGKASANnapi_gro_frags+0x6e/0x1030 net/core/gro.c:758 中的 slab-use-after-free 大小为 8 的读取位于地址 ffff88802ef22c18 执行任务 syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Commsyz.0.17 未受感染 syzkaller #0 PREEMPT(full) 调用跟踪 <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [内联] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h 3150 [内联] napi_frags_skb net/core/gro.c:723 [内联] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [内联] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 按任务 6079 分配kasan_save_stack mm/kasan/common.c:47 [内联] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:330 [ inline] __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558 kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline] napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295 __alloc_skb+0x11e/0x2d0 net/ core/skbuff.c:657 napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811 napi_get_frags+0x69/0x140 net/core/gro.c:673 tun_napi_alloc_frags drivers/net/tun.c:1404 [内联] tun_get_user+ 0x77c/0x3e20 drivers/net/tun.c:1784 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write +0x145/0x250 fs/read_write.c:738 do_s yscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 已由任务释放 6079: kasan_save_stack mm/kasan/common.c 47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576毒害_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [内联] slab_free_hook mm/slub.c:2422 [内联] slab_free mm/slub.c:4695 [内联] kmem_cache_free+0x18f/0x400 mm /slub.c:4797 skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969 netif_skb_check_for_xdp net/core/dev.c:5390 [内联] netif_receive_generic_xdp net/core/dev.c:5431 [内联] do_xdp_generic+0x699/ 0x11a0 net/core/dev.c:5499 tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write +0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x 250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 提交 e6d5dbdd20aa 之后 (xdp添加对在通用模式中运行的 xdp 的多缓冲区支持当附加在 tun_napi_alloc_frags() 中分配的 XDP 程序时可在 skb_pp_cow_data() 中释放原始 skb。但是napi->skb 仍然指向原始 skb请在 XDP 进程之后更新它。 (CVE-2025-39984)

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

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

  - canetas_es58x填充 ndo_change_mtu() 以防止缓冲区溢出 发送 PF_PACKET 可让绕过 CAN 框架逻辑并直接访问 CAN 驱动程序的 xmit() 函数。PF_PACKET 框架执行的唯一检查是确保 skb->len 适合接口的 MTU。
    遗憾的是由于 etas_es58x 驱动程序未填充其 net_device_ops->ndo_change_mtu()因此攻击者可通过执行以下操作来配置无效的 MTU例如$ ip link set can0 mtu 9999使用 ETH_P_CANXL 协议的 PF_PACKET 套接字
    socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));以注入恶意 CAN XL 帧。例如：struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN 驱动程序的 xmit() 函数调用 can_dev_dropped_skb() 以检查 skb 是否有效但遗憾的是在上述情况下恶意数据包能够通过 can_dev_dropped_skb() 检查1. skb->protocol 设为 ETH_P_CANXL这是有效的（函数不会检查实际的设备功能）。 2. 长度为有效的 CAN XL 长度。因此es58x_start_xmit() 收到无法正确处理的 CAN XL 帧并将其错误解释为 CAN(FD) 帧。这可导致缓冲区溢出。例如使用 es581.4 变体帧将调度至 es581_4_tx_can_msg()因此在此函数的开头进行最后的检查 if (can_is_canfd_skb(skb)) return -EMSGSIZE;并到达这一行：
    memcpy(tx_can_msg->data, cf->data, cf->len);在此，cf->len 对应于 CAN XL 帧的标记字段。在之前的示例中，我们将 canxl_frame->flags 设置为 0xff。由于预期的最大长度为 8因此会发生 247 字节的缓冲区溢出填充 net_device_ops->ndo_change_mtu() 以确保接口的 MTU 无法设置为大于 CAN_MTU 或 CANFD_MTU的任何值取决于设备功能。通过修复根本原因这可以防止缓冲区溢出。 (CVE-2025-39988)

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

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

  - MediaTrackGraphImpl::GetInstance() 中存在释放后使用。此漏洞影响 Firefox < 144、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11708)

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

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

  - Firefox ESR 115.28、Firefox ESR 140.3、Thunderbird ESR 140.3、Firefox 143 和 Thunderbird 143 中存在的内存安全缺陷。其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Firefox < 144、Firefox ESR < 115.29、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。
    (CVE-2025-11714)

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

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

  - iommufd在文件描述符中止期间修复争用。fput() 实际上不会同步调用 file_operations release()而是将文件放入工作队列中最终会被释放。这通常没有问题但 iommufd 除外其文件和 iommufd_object 会捆绑到一起。文件将对象视为 private_data 并保留用户引用计数而只要文件存在则预期对象会保持活动状态。当新对象的分配在安装文件之前中止时它将 fput() 文件然后继续立即 kfree() 对象。这会在工作队列完成 fput() 后造成 UAF 并尝试减少用户引用计数。通过让核心代码负责文件生命周期来修复此问题并在中止期间调用 __fput_sync() 以确保在 kfree 之前调用 release()。 __fput_sync() 的算法过于复杂无法在所有对象实现中打开代码。取而代之的是，对象会告知核心代码文件指针的位置，然后核心将处理生命周期。如果对象成功分配则文件将保留用户引用计数且无法破坏 iommufd_object。值得注意的是 close(); ioctl(IOMMU_DESTROY);不会有问题因为 close() 已在使用 fput() 的同步版本。UAF如下所示BUGKASANiommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 中存在 slab-use-after-free 在 addr ffff888059c97804 处大小为 4 的写入 syz.0.46/6164 CPU 0 UID0 PID6164 Commsyz.0.46 未受感染 syzkaller #0 PREEMPT(full) 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 08/18/2025 调用跟踪 <TASK> __dump_stack lib/dump_stack。 c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:183 [内联] kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189 Instrument_atomic_read_write include/linux/instrumented.h:96 [内联] atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [内联] __refcount_dec include/linux/refcount.h:455 [内联] refcount_dec include/linux/refcount.h:476 [内联] iommufd_eventq_fops_re Lease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 __fput+0x402/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2025-39966)

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

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

  - scsitarget target_core_configfs添加长度检查以避免缓冲区溢出 使用 snprintf 写入位于 /drivers/target/target_core_configfs.c 的 target_lu_gp_members_show 函数中的缓冲区 buf 会导致缓冲区溢出。此缓冲区分配的大小为 LU_GROUP_NAME_BUF256 字节。
    snprintf(...) 将多个字符串格式化为包含 HBA 名称 (hba->hba_group.cg_item)、一个斜线字符、一个设备名称 (dev->dev_group.cg_item) 和一个换行符的缓冲区格式化的字符串总长度可能超过256 个字节的缓冲区大小。由于 snprintf() 返回本应写入的总字节数%s/%sn 的长度此值可能超过传递给 memcpy() 的缓冲区长度256 字节这最终将导致函数 memcpy 报告一个缓冲区溢出错误。对 snprintf() 的返回值进行的额外检查可避免此缓冲区溢出。 (CVE-2025-39998)

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

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

  - ALSAusb-audio修复 snd_usbmidi_free 中 UAF 的争用条件之前提交 0718a78f6a9fALSA
    usb-audio删除时正确终止定时器修复了错误定时器引起的 UAF 问题。但是由于此修补程序中添加的错误定时器终止发生在端点删除之后因此尽管罕见但仍会发生 UAF 的争用条件。此外由于 urb 的 kill-cleanup 也缺失因此可在与 urb 相关的中断上下文中访问已释放的内存造成 UAF。因此为防止发生这种情况必须先终止错误定时器和 urb然后再释放堆内存。 (CVE-2025-39997)

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

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

  - 在 Google Chrome 141.0.7390.107 之前的版本中，Safe Browsing 中存在释放后使用漏洞，已破坏渲染器进程的远程攻击者可能利用此漏洞，通过构建的 HTML 页面执行越界内存访问。（Chromium 安全严重性：高）(CVE-2025-11756)

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

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

  - mediatunerxc5000修复 xc5000_release 中的释放后使用。原始代码在 xc5000_release() 中使用 cancel_delayed_work()这不能保证延迟的工作项目 timer_sleep 在已经运行时也能完全完成。这会导致释放后使用的情况其中 xc5000_release() 可能会在 timer_sleep 仍处于活动状态并尝试取消引用 xc5000_priv 时释放 xc5000_priv。一个典型的争用条件如下所示：CPU 0（发布线程）| CPU 1延迟工作回调xc5000_release() | | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | Hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF 将 cancel_delayed_work() 替换为 cancel_delayed_work_sync()以确保 timer_sleep 在取消分配 xc5000_priv 内存之前已正确取消。我们已考虑死锁问题在进程上下文中调用 xc5000_release() 并且未持有 timer_sleep 工作项目可能也需要的任何锁定。因此，_sync() 变体的使用在此处是安全的。最初通过静态分析发现此缺陷。 [hverkuil修复了 Subject: tunner -> tuner 中的拼写错误CVE-2025-39994

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

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

  - 遭到入侵的 Web 进程能够在使用受到操纵的 WebGL 纹理的权限更高的进程中触发越界读取和写入。此漏洞会影响 Firefox < 144、Firefox ESR < 115.29、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11709)

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

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

  - 恶意网页可能利用 OBJECT 标签的 type 属性，在遇到无 content-type 的网络资源时，覆盖浏览器的默认行为。这可能导致站点上存在 XSS该站点不安全地提供无 content-type 标头的文件。此漏洞会影响 Firefox < 144、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11712)

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

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

  - wifirtw89修复 rtw89_core_tx_kick_off_and_wait() 中的释放后使用。当 rtw89_core_tx_kick_off_and_wait() 尝试访问已释放的 skb_data 时观察到一个缺陷 BUGKFENCErtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek 中的释放后使用写入/rtw89/core.c:1110 CPU6 UID0 PID
    41377 Commkworker/u64:24 未受感染 6.17.0-rc1+ #1 PREEMPT(lazy) 硬件名称QEMU Standard PC (i440FX + PIIX,1996)、BIOS edk2-20250523-14.fc42 05/23/2025 Workqueueevents_unbound cfg80211_wiphy_work [ cfg80211] 0x0000000020309d9d中的释放后使用写入 kfence-#251中rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete /net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net /wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c :3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x 86/entry/entry_64.S:258 kfence-#2510x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache 在 77869.159548s0.009551s 前由 cpu 6 上的任务 41377 分配
    __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net /wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless /realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek /rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry /entry_64.S:258 由 cpu 9 上的任务 1045 在 77869.168393s 前释放0.001557s ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_ pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c :676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/ softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c 1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 争用所导致等待线程完成线程 rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* 发出信号完成
    ---truncated--- (CVE-2025-40000)

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

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

  - i40e添加 VF 过滤器的最大边界检查 未对 VF 可以请求的最大过滤器进行检查。添加之。
    (CVE-2025-39968)

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

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

  - mediai2ctc358743修复由探测中的孤立定时器造成的释放后使用缺陷 state->timer 是循环定时器在重新配置自身时会计划 work_i2c_poll 和 delayed_work_enable_hotplug。使用 timer_delete() 无法保证定时器在遭到破坏时不再运行同样如果已经在执行cancel_delayed_work() 也无法确保 delayed_work_enable_hotplug 终止。
    在定时器初始化之后探测失败期间这些对象可作为孤立对象继续运行并通过 tc358743_irq_poll_timer 引用已释放的 tc358743_state 对象。以下是 KASAN 捕获的跟踪信息。缺陷KASAN任务 swapper/1/0 ... 调用跟踪 <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ?
    __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 __run_timer_base.part.0+0x7d7/0x8c0
    __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ?
    __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 tmigr_update_events+0x280/0x740
    _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ?
    __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ?
    _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440
    __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ?
    __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ>... 由任务 141 分配
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90
    __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190
    __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670
    __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由任务 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190
    __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670
    __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...
    将 timer_delete() 替换为 timer_delete_sync()并将 cancel_delayed_work() 替换为 cancel_delayed_work_sync() 以确保在清理资源之前正确终止定时器和工作项目。最初通过静态分析发现此缺陷。为了重现和测试，我通过内核模块创建了 tc358743 设备的功能仿真，并通过 debugfs 接口引入了错误。 (CVE-2025-39995)

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

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

  - fbcon修复 fbcon_do_set_font 中的整数溢出 修复 fbcon_do_set_font() 中的整数溢出漏洞这些漏洞在处理用户控制的字体参数时字体大小计算可能溢出。在以下情况下发生这些漏洞： 1. CALC_FONTSZ(h,itch,charcount) 对受用户控制、可溢出的值执行 h *pith *charcount 乘法。 2. FONT_EXTRA_WORDS * sizeof(int) + 大小加法也会溢出 3. 这导致分配的内存比预期小从而在字体数据复制期间导致缓冲区溢出。添加使用 check_mul_overflow() 和 check_add_overflow() 内核帮助程序的显式溢出检查以便在分配之前安全验证所有大小计算。
    (CVE-2025-39967)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue This fixes the following UAF caused by not properly locking hdev when processing HCI_EV_NUM_COMP_PKTS: BUG: KASAN: slab-use-after-free in hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036 Read of size 4 at addr ffff8880740f0940 by task kworker/u11:0/54 CPU: 1 UID:
    0 PID: 54 Comm: kworker/u11:0 Not tainted 6.16.0-rc7 #3 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci1 hci_rx_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036 hci_num_comp_pkts_evt+0x1c8/0xa50 net/bluetooth/hci_event.c:4404 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline]
    __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 le_conn_complete_evt+0x3d6/0x1220 net/bluetooth/hci_event.c:5628 hci_le_enh_conn_complete_evt+0x189/0x470 net/bluetooth/hci_event.c:5794 hci_event_func net/bluetooth/hci_event.c:7474 [inline] hci_event_packet+0x78c/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Freed by task 9572:
    kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline]
    __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_abort_conn_sync+0x5d1/0xdf0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 (CVE-2025-39983)

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

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

  - smb客户端修复 smb2_compound_op() 中错误的索引引用 在 smb2_compound_op() 中处理每个命令响应的循环在访问响应缓冲区时会使用错误的索引。这种不正确的索引操作会导致对命令结果的不正确处理。此外如果未正确计算的索引大于或等于 MAX_COMPOUND 也会造成越界访问。 (CVE-2025-39975)

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

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

  - net/mlx5fs修复流计数器释放中的 UAF 修复由于释放 mlx5_cmd_hws_delete_fte() 中本地流计数器的 HWS 操作而导致的内核跟踪 [1]其中 HWS 操作 refcount 和 mutex 未初始化计数器 struct可能已在删除规则时得到释放。通过添加缺少的初始化并添加本地流计数器结构的 refcount来修复此问题。 [1] 内核日志调用跟踪
    <TASK> dump_stack_lvl+0x34/0x48 mlx5_fs_put_hws_action.part.0.cold+0x21/0x94 [mlx5_core] mlx5_fc_put_hws_action+0x96/0xad [mlx5_core] mlx5_fs_destroy_fs_actions+0x8b/0x152 [mlx5_core] mlx5_cmd_hws_delete_fte+0x5a/0xa0 [mlx5_core] del_hw_fte+0x1ce/0x260 [mlx5_core] mlx5_del_flow_rules+0x12d/0x240 [mlx5_core] ? ttwu_queue_wakelist+0xf4/0x110 mlx5_ib_destroy_flow+0x103/0x1b0 [mlx5_ib] uverbs_free_flow+0x20/0x50 [ib_uverbs] destroy_hw_idr_uobject+0x1b/0x50 [ib_uverbs] uverbs_destroy_uobject+0x34/0x1a0 [ib_uverbs] uobj_destroy+0x3c/0x80 [ib_uverbs] ib_uverbs_run_method+0x23e/0x360 [ib_uverbs] ? uverbs_finalize_object+0x60/0x60 [ib_uverbs] ib_uverbs_cmd_verbs+0x14f/0x2c0 [ib_uverbs] ? do_tty_write+0x1a9/0x270 ? file_tty_write.constprop.0+0x98/0xc0 new_sync_write+0xfc/0x190 ib_uverbs_ioctl+0xd7/0x160 [ib_uverbs] __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x59/0x90 (CVE-2025-39979)

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

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

  - bpf检查 get_helper_proto 内核中的 helper 函数是否有效机器人报告了验证器缺陷 [1]其中由于禁用了 config 选项helper 函数指针可能为 NULL。正如 Alexei 所建议的我们可以直接在 get_helper_proto 中检查这一点。用 BPF_PTR_POISON 标记 tail_call 辅助函数因为在设计时未使用它。 [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com(CVE-2025-39990)

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

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

  - 已修复 Linux 内核中的下列漏洞：futex: Use correct exit on failure from futex_hash_allocate_default() copy_process() uses the wrong error exit path from futex_hash_allocate_default(). After exiting from futex_hash_allocate_default(), neither tasklist_lock nor siglock has been acquired. The exit label bad_fork_core_free unlocks both of these locks which is wrong.
    The next exit label, bad_fork_cancel_cgroup, is the correct exit. sched_cgroup_fork() did not allocate any resources that need to freed. Use bad_fork_cancel_cgroup on error exit from futex_hash_allocate_default().
    (CVE-2025-39976)

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

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

  - canhi311x填充 ndo_change_mtu() 以防止缓冲区溢出 发送 PF_PACKET允许绕过 CAN 框架逻辑并直接访问 CAN 驱动程序的 xmit() 函数。PF_PACKET 框架执行的唯一检查是确保 skb->len 适合接口的 MTU。
    遗憾的是由于 sun4i_can 驱动程序未填充其 net_device_ops->ndo_change_mtu()攻击者可通过执行以下操作来配置无效的 MTU例如$ ip link set can0 mtu 9999使用 ETH_P_CANXL 协议的 PF_PACKET 套接字
    套接字(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) 中注入恶意 CAN XL 帧。例如：struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN 驱动程序的 xmit() 函数调用 can_dev_dropped_skb() 以检查 skb 是否有效但遗憾的是在上述情况下恶意数据包能够通过 can_dev_dropped_skb() 检查1. skb->protocol 设为 ETH_P_CANXL这是有效的（函数不会检查实际的设备功能）。 2. 长度为有效的 CAN XL 长度。因此hi3110_hard_start_xmit() 收到它无法正确处理的 CAN XL 帧并将其错误解释为 CAN 帧。驱动程序将按原样使用 frame->len而不进行进一步检查。这可能导致此后 hi3110_hw_tx() 中此行的缓冲区溢出 memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);在此，frame->len 对应于 CAN XL 帧的 flags 字段。在之前的示例中，我们将 canxl_frame->flags 设置为 0xff。由于预期的最大长度为 8因此会发生 247 字节的缓冲区溢出填充 net_device_ops->ndo_change_mtu() 以确保接口的 MTU 无法设置为大于 CAN_MTU 的任何值。通过修复根本原因这可以防止缓冲区溢出。 (CVE-2025-39987)

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

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

  - cansun4i_can填充 ndo_change_mtu() 以防止缓冲区溢出 发送 PF_PACKET 允许绕过 CAN 框架逻辑并直接访问 CAN 驱动程序的 xmit() 函数。PF_PACKET 框架执行的唯一检查是确保 skb->len 适合接口的 MTU。
    遗憾的是由于 sun4i_can 驱动程序未填充其 net_device_ops->ndo_change_mtu()攻击者可通过执行以下操作来配置无效的 MTU例如$ ip link set can0 mtu 9999使用 ETH_P_CANXL 协议的 PF_PACKET 套接字
    套接字(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) 中注入恶意 CAN XL 帧。例如：struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN 驱动程序的 xmit() 函数调用 can_dev_dropped_skb() 以检查 skb 是否有效但遗憾的是在上述情况下恶意数据包能够通过 can_dev_dropped_skb() 检查1. skb->protocol 设为 ETH_P_CANXL这是有效的（函数不会检查实际的设备功能）。 2. 长度为有效的 CAN XL 长度。因此sun4ican_start_xmit() 收到它无法正确处理的 CAN XL 帧并将其错误解释为 CAN 帧。这可导致缓冲区溢出。驱动程序将按原样使用 cf->len而不在此行上进行进一步检查 dlc = cf->len;在此，cf->len 对应于 CAN XL 帧的标记字段。在之前的示例中，我们将 canxl_frame->flags 设置为 0xff。由于最大预期长度为 8因此在执行以下操作时在下方几行会发生 247 字节的缓冲区溢出 for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + ( dreg + i * 4));填充 net_device_ops->ndo_change_mtu() 以确保接口的 MTU 无法设置为大于 CAN_MTU 的任何值。通过修复根本原因这可以防止缓冲区溢出。 (CVE-2025-39986)

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

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

  - Firefox ESR 140.3、Thunderbird ESR 140.3、Firefox 143 和 Thunderbird 143 中存在内存安全缺陷。
    其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Firefox < 144、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11715)

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

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

  - 受损 Web 进程使用恶意 IPC 消息可导致特权浏览器进程向受损进程泄露其内存块。此漏洞会影响 Firefox < 144、Firefox ESR < 115.29、Firefox ESR < 140.4、Thunderbird < 144 和 Thunderbird < 140.4。 (CVE-2025-11710)

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

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

  - i40e修复 action_meta 的输入验证逻辑 修复了检查“大于或等于”的条件以防止 OOB 取消引用。 (CVE-2025-39970)

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

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

  - nexthop当 nexthop 在组中时禁止 FDB 状态变更 内核禁止使用 FDB nexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB 创建非 FDB nexthop 组nexthop 组不能有 fdb nexthops。反之亦然# ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb 错误FDB nexthop 组只能拥有 fdb nexthops。但是只要没有路由指向非 FDB nexthop 组则内核允许将 nexthop 类型从 FDB 更改为非 FDB反之亦然# ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop添加 id 6 group 5 # ip nexthop 通过 192.0.2.2 fdb 替换 id 5 # echo $? 0 此配置无效并 198.51.100.1可能导致 NPD [1]因为 FDB 198.51.100.1 nexthops are not关联与 nexthop 设备在组中# ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb 错误：在组中时无法更改 nexthop FDB 状态。 [1] BUGkernel 空指针取消引用, 地址00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping 未受感染 6.17.0-rc6-virtme- gb65678cacc03 #1 PREEMPT(随意) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP0010:fib_lookup_good_nhc+0x1e/0x80 [...] 调用跟踪 <TASK> fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60
    __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53CVE-2025-39980

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

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

  - i40e修复 i40e_validate_queue_map 中的 idx 验证迭代 i40e_validate_queue_map() 中的 vf->ch[idx] 时确保 idx 处于活动/初始化的 TC 范围内。 (CVE-2025-39972)

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

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

  - 已通过改进内存处理解决此问题。此问题已在 Safari 26、iOS 26 和 iPadOS 26、macOS Tahoe 26、tvOS 26、visionOS 26、watchOS 26 中修复。处理恶意构建的 Web 内容或可导致进程意外崩溃。(CVE-2025-43343)

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

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

  - mmswap在 VMA 上操作之前检查稳定地址空间 在从 swapoff 路径调用的 unuse_mm() 中遍历 vmas 时可能命中零条目并对其进行访问导致 OOPS无法在 中处理内核空指针取消引用virtual address 0000000000000446--> 正在将 XA_ZERO_ENTRY 上偏移 0x40 处的内存加载为 address。Mem abort infoMem abort infoESR = 0x0000000096000005 EC = 0x25DABT当前 EL，IL = 32 位 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x05：级别 1 转换错误 此问题表现为进程上的 fork() 和 swapoff 之间的争用: fork(dup_mmap()) swapoff(unuse_mm) --------------- ------------- ---- 1) 使用 __mt_dup() 构建相同的 mtree。 2) copy_pte_range()--> copy_nonpresent_pte()dst mm 已添加到 mmlist 中以便对 swapoff 操作可见。 3) 致命信号被发送到父进程在 fork 期间为当前进程从而跳过 vmas 的复制并使用 XA_ZERO_ENTRY 作为此进程在 exit_mmap() 期间提供帮助的标记来标记 vma 范围。 4) 在作为 2 一部分添加到“mmlist”的“mm”上尝试 swapoff。5) unuse_mm()迭代此“mm”的 vma 将命中非空零条目并在此基础上操作零条目作为 vma 导致 oops。正确的补丁应该是在释放 mmap 锁时不将此部分有效的树状结构暴露给其他人[1] 解决了此问题。更简单的解决方案是检查 MMF_UNSTABLE因为它在 mm_struct 未在 dup_mmap() 中完全初始化时进行设置。感谢 Liam/Lorenzo/David 在修复此问题时提供的所有建议。 (CVE-2025-39992)

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

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

  - wifiath11k修复 ath11k_qmi_m3_load() 中的空取消引用如果 ab->fw.m3_data 指向数据则 fw 指针保持为空。此外如果未分配 m3_mem则 fw 会取消引用以传递至 ath11k_err 函数。将 fw->size 替换为 m3_len。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2025-39991)

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

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

  - Bluetoothhci_event修复 hci_acl_create_conn_sync 中的 UAF 这可修复 hci_acl_create_conn_sync 中的以下 UFA其中可能释放了命令提交 (conn->state == BT_OPEN)仍然待定的连接也因为 hci_le_create_conn_sync 之类的项目也可能发生此问题将其修复为well
    BUGKASAN由任务 kworker/u11:2/9541 CPU: 1 UID: 0 PID: 9541 Comm
    kworker/u11:2 未受感染 6.16.0-rc7 #3 PREEMPT(full) 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.10.2-1ubuntu1 04/01/2014 工作队列hci3 hci_cmd_sync_work 调用跟踪 <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [内联] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/ report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 内核/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/ 0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK> 由任务分配 123736kasan_save_stack mm/kasan/common.c:47 [内联] kasan_save_track+0x3e/0x80 mm/kasan/c omon.c:68毒害_kmalloc_redzone mm/kasan/common.c:377 [内联] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [内联] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [内联] kzalloc_noprof include/linux/slab.h:1039 [内联] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/ bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c 1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [内联]
    __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145 /0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由任务 103680 释放
    kasan_save_stack mm/kasan/common.c:47 [内联] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576毒害_slab_object mm/kasan/common.c 247 [内联]
    __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [内联] slab_free_hook mm/slub.c:2381 [内联] slab_free mm/slub.c:4643 [内联] kfree +0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [内联] kobject_release lib/kobject.c:720 [内联] kref_put include/linux/kref.h:65 [内联] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event .c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work 内核/工作队列。 c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86 /kernel/process .c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour
    ---truncated--- (CVE-2025-39982)

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

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

  - i40e修复获取资源中 VF 状态的验证 VF 状态 I40E_VF_STATE_ACTIVE 不是 VF 实际处于活动状态的唯一状态因此不应使用它来确定是否允许 VF 获取资源。
    使用仅在 i40e_vc_get_vf_resources_msg() 中设置并在重置期间清除的 I40E_VF_STATE_RESOURCES_LOADED。 (CVE-2025-39969)

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

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

  - mediarc修复 imon_disconnect() 的争用 Syzbot 报告一个 KASAN 问题如下 BUGKASAN__create_pipe include/linux/usb.h:1945 中的释放后使用 [inline] BUGKASAN: use-after- send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 中释放地址 ffff8880256fb000 中大小为 4 的读取由任务 syz-executor314/4465 CPU: 2 PID4465 Commsyz-executor314 未受感染 6.0.0-rc1 -syzkaller #0 硬件名称
    QEMU Standard PC (Q35 + ICH92009)BIOS 1.14.0-2 04/01/2014 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm /kasan/report.c:317 [内联] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h 1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+ 0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd iMON 驱动程序不当在未与设备的活动用户协调的情况下发布 imon_disconnect 中的 usb_device 引用。具体来说字段 usbdev_intf0 和 usbdev_intf1 不受用户计数器 (ictx->users) 的保护。在探测期间imon_init_intf0 或 imon_init_intf1 根据接口递增 usb_device 引用计数。但是在断开连接期间系统会无条件调用 usb_put_dev而与实际使用情况无关。因此如果断开连接后 vfd_write 或其他操作仍在进行中则可导致 usb_device 指针的释放后使用。线程 1 vfd_write 线程 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0)else usb_put_dev(ictx->usbdev_intf1) ...
    while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAFelse pipe = usb_sndctrlpipe(ictx->usbdev_intf0, 0) UAF 通过检查所有编写器路径中的 ictx->disconnected在断开连接后保护对 usbdev_intf0 和 usbdev_intf1 的访问。如果设备不再存在则使用 send_packet()、vfd_write()、lcd_write() 和 display_open() 中的 -ENODEV 添加提前返回。在 ictx->lock 下设置并读取 ictx->disconnected 以确保内存同步。设置标记以与任何正在进行的操作同步之前先获取 imon_disconnect() 中的锁。确保写入器在断开连接后于 USB 核心继续进行清理之前及早安全退出。由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。
    (CVE-2025-39993)

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

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

  - i40e修复配置队列消息中的 idx 验证迭代 i40e_vc_config_queues_msg 中的 vf->ch[idx] 时确保 idx 处于活动/初始化的 TC 范围内。 (CVE-2025-39971)

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

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

  - mediab2c2修复由 flexcop_pci_remove 中的 irq_check_work 造成的释放后使用发生释放后使用原始代码使用 flexcop_pci_remove() 中的 cancel_delayed_work()因此不能保证延迟的工作项目 irq_check_work 在已运行时完全完成。这会导致释放后使用情况其中 flexcop_pci_remove() 可能会在 irq_check_work 仍处于活动状态时释放 flexcop_device并尝试取消引用设备。一个典型的争用条件如下所示： CPU 0删除| CPU 1延迟工作回调 flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_pci_irq_check_work() flexcop_device_kfree(fc_pci->fc_dev) | flexcop_device_kfree | fc = fc_pci->fc_dev; // UAF KASAN 报告证实了此问题
    ================================================== ================ 缺陷KASAN中的 slab 释放后使用
    __run_timer_base.part.0+0x7d7/0x8c0 由任务 bash/135 在地址 ffff8880093aa8c8 执行的大小为 8 的写入 ... 调用跟踪 <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0
    __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ>...
    按任务分配 1kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90
    __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 real_probe+0x1ca/0x5c0
    __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... 将 cancel_delayed_work() 替换为 cancel_delayed_work_sync() 以确保正确取消延迟工作项目并确保在取消分配设备内存之前已完成任何正在执行的延迟工作。最初通过静态分析发现此缺陷。为了重现和测试该问题，我在 QEMU 中模拟了 B2C2 FlexCop PCI 设备，并在 flexcop_pci_irq_check_work() 函数中引入了人为的延迟，以增加触发该缺陷的可能性。
    (CVE-2025-39996)

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

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

  - i40e添加对 ring_len 参数的验证 虚拟函数 (VF) 提供的“ring_len”参数未经任何验证即直接分配给硬件内存上下文 (HMC)。要解决此问题请为 Tx 和 Rx 队列长度引入上限检查。硬件支持的最大描述符数量为 8k-32。此外强制执行对齐限制Tx 环必须是 8 的倍数Rx 环必须是 32 的倍数。(CVE-2025-39973)

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

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

  - 已修复 Linux 内核中的下列漏洞：blk-mq: fix blk_mq_tags double free while nr_requests grown In the case user trigger tags grow by queue sysfs attribute nr_requests, hctx->sched_tags will be freed directly and replaced with a new allocated tags, see blk_mq_tag_update_depth(). The problem is that hctx->sched_tags is from elevator->et->tags, while et->tags is still the freed tags, hence later elevator exit will try to free the tags again, causing kernel panic.
    Fix this problem by replacing et->tags with new allocated tags as well. Noted there are still some long term problems that will require some refactor to be fixed thoroughly[1]. [1] https://lore.kernel.org/all/20250815080216.410665-1-yukuai1@huaweicloud.com/ (CVE-2025-39999)

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

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

  - canmcba_usb填充 ndo_change_mtu() 以防止缓冲区溢出 发送 PF_PACKET 可导致绕过 CAN 框架逻辑并直接访问 CAN 驱动程序的 xmit() 函数。PF_PACKET 框架执行的唯一检查是确保 skb->len 适合接口的 MTU。
    遗憾的是由于 mcba_usb 驱动程序未填充其 net_device_ops->ndo_change_mtu()攻击者可通过执行以下操作来配置无效的 MTU例如$ ip link set can0 mtu 9999使用 ETH_P_CANXL 协议的 PF_PACKET 套接字
    套接字(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) 中注入恶意 CAN XL 帧。例如：struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN 驱动程序的 xmit() 函数调用 can_dev_dropped_skb() 以检查 skb 是否有效但遗憾的是在上述情况下恶意数据包能够通过 can_dev_dropped_skb() 检查1. skb->protocol 设为 ETH_P_CANXL这是有效的（函数不会检查实际的设备功能）。 2. 长度为有效的 CAN XL 长度。因此mcba_usb_start_xmit() 收到它无法正确处理的 CAN XL 帧并将其错误解释为 CAN 帧。这可导致缓冲区溢出。驱动程序将按原样使用 cf->len 而不对这些行进行进一步检查usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc);在此，cf->len 对应于 CAN XL 帧的标记字段。在之前的示例中，我们将 canxl_frame->flags 设置为 0xff。由于预期的最大长度为 8因此会发生 247 字节的缓冲区溢出填充 net_device_ops->ndo_change_mtu() 以确保接口的 MTU 无法设置为大于 CAN_MTU 的任何值。通过修复根本原因这可以防止缓冲区溢出。
    (CVE-2025-39985)

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

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

  - futex在 requeue-PI 期间防止释放后使用 syzbot 设法触发以下争用 T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * 超时/ 信号唤醒 T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is垃圾 /* back */ wake_up_state(q->task, TASK_NORMAL);在这种情况下futex_wait_requeue_pi() 能够在不使用 futex_q::lock_ptr 进行同步的情况下离开。可通过在更新 futex_q::requeue_state 之前读取 futex_q::task 来避免此问题。不需要 task_struct 中的引用因为在保留 spinlock_t 的情况下调用 requeue_pi_wake_futex()这意味着存在 RCU 读取部分。即使 T1 立即终止在 T2 的 wake_up_state() 期间task_struct 也将保持有效。在 futex_requeue_pi_complete() 之前，在 futex_q::task 上设置 READ_ONCE 就足够了，因为这可确保在更新状态之前读取变量。在更新重新排队状态之前读取 futex_q::task 将其用于后续唤醒。 (CVE-2025-39977)

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

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

  - 已修复 Linux 内核中的下列漏洞：tracing/osnoise: Fix slab-out-of-bounds in _parse_integer_limit() When config osnoise cpus by write() syscall, the following KASAN splat may be observed: BUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130 Read of size 1 at addr ffff88810121e3a1 by task test/447 CPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_report+0xcb/0x610 kasan_report+0xb8/0xf0
    _parse_integer_limit+0x103/0x130 bitmap_parselist+0x16d/0x6f0 osnoise_cpus_write+0x116/0x2d0 vfs_write+0x21e/0xcc0 ksys_write+0xee/0x1c0 do_syscall_64+0xa8/0x2a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This issue can be reproduced by below code: const char
    *cpulist = 1; int fd=open(/sys/kernel/debug/tracing/osnoise/cpus, O_WRONLY); write(fd, cpulist, strlen(cpulist)); Function bitmap_parselist() was called to parse cpulist, it require that the parameter 'buf' must be terminated with a '\0' or '\n'. Fix this issue by adding a '\0' to 'buf' in osnoise_cpus_write(). (CVE-2025-39974)

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

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

  - 在 Samba 的 vfs_streams_xattr 模块中发现一个缺陷未初始化的堆内存可被写入替代数据流中。这允许经过认证的用户读取可能包含敏感数据的残留内存内容从而导致信息泄露漏洞。 (CVE-2025-9640)

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

ID	名称	严重性
271571	Linux Distros 未修补的漏洞：CVE-2023-53714	medium
271570	Linux Distros 未修补的漏洞：CVE-2023-53720	medium
271569	Linux Distros 未修补的漏洞：CVE-2023-53706	medium
271568	Linux Distros 未修补的漏洞：CVE-2023-53732	medium
271567	Linux Distros 未修补的漏洞：CVE-2025-59024	medium
271566	Linux Distros 未修补的漏洞：CVE-2025-11731	low
271565	Linux Distros 未修补的漏洞：CVE-2025-11711	medium
271564	Linux Distros 未修补的漏洞：CVE-2025-39978	high
271563	Linux Distros 未修补的漏洞：CVE-2025-39981	high
271562	Linux Distros 未修补的漏洞：CVE-2025-39984	high
271561	Linux Distros 未修补的漏洞：CVE-2025-39988	high
271560	Linux Distros 未修补的漏洞：CVE-2025-11708	critical
271559	Linux Distros 未修补的漏洞：CVE-2025-11714	high
271558	Linux Distros 未修补的漏洞：CVE-2025-39966	high
271557	Linux Distros 未修补的漏洞：CVE-2025-39998	high
271556	Linux Distros 未修补的漏洞：CVE-2025-39997	medium
271555	Linux Distros 未修补的漏洞：CVE-2025-11756	high
271554	Linux Distros 未修补的漏洞：CVE-2025-39994	high
271553	Linux Distros 未修补的漏洞：CVE-2025-11709	critical
271552	Linux Distros 未修补的漏洞：CVE-2025-11712	medium
271551	Linux Distros 未修补的漏洞：CVE-2025-40000	medium
271550	Linux Distros 未修补的漏洞：CVE-2025-39968	medium
271549	Linux Distros 未修补的漏洞：CVE-2025-39995	high
271548	Linux Distros 未修补的漏洞：CVE-2025-39967	high
271547	Linux Distros 未修补的漏洞：CVE-2025-39983	medium
271546	Linux Distros 未修补的漏洞：CVE-2025-39975	high
271545	Linux Distros 未修补的漏洞：CVE-2025-39979	high
271544	Linux Distros 未修补的漏洞：CVE-2025-39990	medium
271543	Linux Distros 未修补的漏洞：CVE-2025-39976	medium
271542	Linux Distros 未修补的漏洞：CVE-2025-39987	high
271541	Linux Distros 未修补的漏洞：CVE-2025-39986	high
271540	Linux Distros 未修补的漏洞：CVE-2025-11715	high
271539	Linux Distros 未修补的漏洞：CVE-2025-11710	critical
271538	Linux Distros 未修补的漏洞：CVE-2025-39970	medium
271537	Linux Distros 未修补的漏洞：CVE-2025-39980	medium
271536	Linux Distros 未修补的漏洞：CVE-2025-39972	high
271535	Linux Distros 未修补的漏洞：CVE-2025-43343	critical
271534	Linux Distros 未修补的漏洞：CVE-2025-39992	medium
271533	Linux Distros 未修补的漏洞：CVE-2025-39991	medium
271532	Linux Distros 未修补的漏洞：CVE-2025-39982	high
271531	Linux Distros 未修补的漏洞：CVE-2025-39969	medium
271530	Linux Distros 未修补的漏洞：CVE-2025-39993	high
271529	Linux Distros 未修补的漏洞：CVE-2025-39971	high
271528	Linux Distros 未修补的漏洞：CVE-2025-39996	medium
271527	Linux Distros 未修补的漏洞：CVE-2025-39973	high
271526	Linux Distros 未修补的漏洞：CVE-2025-39999	high
271525	Linux Distros 未修补的漏洞：CVE-2025-39985	high
271524	Linux Distros 未修补的漏洞：CVE-2025-39977	high
271523	Linux Distros 未修补的漏洞：CVE-2025-39974	high
271522	Linux Distros 未修补的漏洞：CVE-2025-9640	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

low

medium

high

high

high

high

critical

high

high

high

medium

high

high

critical

medium

medium

medium

high

high

medium

high

high

medium

medium

high

high

high

critical

medium

medium

high

critical

medium

medium

high

medium

high

high

medium

high

high

high

high

high

medium