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

  - Redis 是一个持续存在于磁盘上的开源内存中数据库。 8.2.1 及更低版本允许经过认证的用户使用特别构建的 Lua 脚本造成整数溢出并可能导致远程代码执行。此问题存在于所有具有 Lua 脚本的 Redis 版本中。此问题已在 8.2.2 版本中修复。(CVE-2025-46817)

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

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

  - Redis 是一个持续存在于磁盘上的开源内存中数据库。 8.2.1 及更低版本允许经身份验证的用户使用特别构建的 Lua 脚本操纵不同的 LUA 对象并且可能在其他用户的上下文中运行自己的代码。此问题存在于所有具有 LUA 脚本的 Redis 版本中。此问题已在 8.2.2 版本中修复。在不修补 redis-server 可执行文件的情况下缓解此问题的一个变通方案是防止用户执行 LUA 脚本。可通过限制 EVAL 和 FUNCTION 命令系列使用 ACL 来阻止脚本来实现此目的。 (CVE-2025-46818)

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

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

  - 发现 QEMU 中存在一个缺陷。如果 QIOChannelWebsock 对象在等待完成握手时被释放GSource 会泄漏。这可导致稍后触发回调并在使用通道时触发释放后使用。对 VNC WebSocket 端口具有网络访问权限的恶意客户端可滥用此缺陷在 VNC 客户端认证之前的 WebSocket 握手期间造成拒绝服务。 (CVE-2025-11234)

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

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

  - Redis 是一个持续存在于磁盘上的开源内存中数据库。 8.2.1 及更低版本允许经身份验证的用户使用特别构建的 LUA 脚本读取越界数据或使服务器崩溃以及后续的拒绝服务。此问题存在于所有具有 Lua 脚本的 Redis 版本中。此问题已在 8.2.2 版本中修复。在不修复 redis-server 可执行文件的情况下解决此问题是为了防止用户执行 Lua 脚本。可通过限制 EVAL 和 FUNCTION 命令系列使用 ACL 来阻止脚本来实现此目的。 (CVE-2025-46819)

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

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

  - smb 客户端使 smbd_destroy() 调用 disable_work_sync(&info->post_send_credits_work) 在 smbd_destroy() 中我们可能会破坏内存因此最好等待 post_send_credits_work 不再待定且永远不会再次启动。实际上我刚在 drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 使用 rxe: WARNING: CPU: 0 PID: 138 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ?
    __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ?
    __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [5305.687933] [ T138] worker_thread+0x87f/0x1570 ... 表示在 rdma_destroy_qp() 之后调用了 rxe_post_recv。发生这种情况的原因是 ib_drain_qp() 触发了 put_receive_buffer() 并调用了
    queue_work(info->workqueue, &info->post_send_credits_work); (CVE-2025-39932)

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

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

  - umvirtio_uml修复探测中 put_device 之后的释放后使用当 register_virtio_device() 在 virtio_uml_probe() 中失败时代码会设置 vu_dev->registered = 1即使设备未成功注册。这可导致释放后使用或其他问题。 (CVE-2025-39951)

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

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

  - tls确保在标头虚假时中止流 通常我们会等待套接字缓冲整个记录然后才能为其提供服务。但是，如果套接字的缓冲区很小，我们会尽快读取数据，以防连接停止。确保我们在发现记录实际无效时立即中止连接。重试解析本身没有问题但由于我们每次在解析之前都会复制一些数据因此可使分配的 skb 空间溢出。套接字中没有足够数据来预先解析长度的压力构建一个场景是相当困难的。 syzbot 通过为我们提供小型 OOB 发送中的标头找到了执行此操作的方法然后使用大型正常发送填入 recvbuf。确保 tls_rx_msg_size() 中止 strp如果到达无效记录则实际上无法恢复。 (CVE-2025-39946)

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

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

  - ksmbdsmbdirect验证 smb_direct_data_transfer 的 data_offset 和 data_length 字段 如果 smb_direct_data_transfer 结构的 data_offset 和 data_length 无效则可能发生越界问题。此修补程序验证 recv_done 中的 data_offset 和 data_length 字段。 (CVE-2025-39943)

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

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

  - cnic修复 cnic_delete_task 中的释放后重用缺陷。原始代码使用 cnic_cm_stop_bnx2x_hw() 中的 cancel_delayed_work()因此不能保证延迟的工作项目“delete_task”在已经运行时也完全完成。此外延迟的工作项目是循环cnic_cm_stop_bnx2x_hw() 中的 flush_workqueue() 仅会阻断和等待在其调用之前已排入工作队列的工作项目。调用 flush_workqueue() 之后提交的任何工作项目不包含在刷新操作等待的任务集中。这意味着在循环工作项目完成执行后工作队列中可能仍然存在延迟的工作项目。这会导致释放后使用情况其中 cnic_dev 由 cnic_free_dev() 取消分配而 delete_task 保持活动状态并尝试取消引用 cnic_delete_task() 中的 cnic_dev。一个典型的争用条件如下所示： CPU 0清理| CPU 1延迟工作回调 cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | cnic_delete_task() ... cancel_delayed_work() | /* queue_delayed_work() flush_workqueue() | queue_delayed_work()在 flush_workqueue() 之后执行*/ | queue_delayed_work() cnic_free_dev(dev)//释放 | | cnic_delete_task() | // dev = cp->dev; //使用“将 cancel_delayed_work() 替换为 cancel_delayed_work_sync()”可确保在 cnic_dev 释放之前正确取消循环延迟工作项目并完成该工作项目任何正在进行的执行。此外由于 cancel_delayed_work_sync() 使用
    __flush_work(work, true) 同步等待任何当前正在执行的工作实例完成flush_workqueue() 就变得多余应该将其删除。此缺陷 是通过静态分析发现的。为重现此问题并验证修复后的效果我在 QEMU 中模拟了 cnic PCI 设备并引入了有意的延迟例如在 cnic_delete_task() 函数内插入对 ssleep() 的调用以增加触发此缺陷的可能性。 (CVE-2025-39945)

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

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

  - ice修复多缓冲区帧上的 Rx 页面泄漏 ice_put_rx_mbuf() 函数会为当前帧中的每个缓冲区处理调用 ice_put_rx_buf()。此函数作为处理 ice 驱动程序中多缓冲区 XDP 支持的一部分引入。其工作方式如下：迭代缓冲区，从 first_desc 直到 1 加上帧中的碎片总数，在执行 XDP 程序之前就开始缓存。如果硬件发布大小为 0 的描述符则 ice_put_rx_mbuf() 中使用的逻辑会中断。系统会跳过此类描述符并且不会将其作为 ice_add_xdp_frag 中的片段添加。由于缓冲区未被计为片段因此我们不会在 ice_put_rx_mbuf() 中对其进行迭代从而不会调用 ice_put_rx_buf()。由于我们不调用 ice_put_rx_buf()因此我们不会尝试重新使用或释放该页面。这会在环中留下一个过时页面因为我们不会增加 next_to_alloc。ice_reuse_rx_page() 假设 next_to_alloc 已正确递增并且其始终指向带有空页面的缓冲区。由于此函数不进行检查因此它会愉快地在 next_to_alloc 缓冲区顶部回收页面从而丢失对旧页面的跟踪。请注意此泄漏仅会在多缓冲区帧发生。ice_put_rx_mbuf() 函数始终至少处理一个缓冲区因此单缓冲区帧始终得到正确处理。目前尚不清楚为什么硬件有时会向我们提供大小为 0 的描述符但在 9K MTU 使用的巨型帧中稍微有规则地发生这种情况。为了修复 ice_put_rx_mbuf()我们需要确保在 first_desc 和 next_to_clean 之间的所有缓冲区上调用 ice_put_rx_buf()。借用用于此相同目的的 i40e 中类似函数的逻辑。在 ice_get_pgcnts() 中也使用相同的逻辑。不只是迭代片段数而是使用一个迭代的循环直到当前索引达到刚刚过去的当前帧的 next_to_clean 元素。与 i40e 不同ice_put_rx_mbuf() 函数会在指示数据包末尾的帧的最后一个缓冲区中调用 ice_put_rx_buf()。对于线性多缓冲区帧，调整 pagecnt_bias 时需要多加注意。XDP 程序可能会释放帧末尾的片段在这种情况下片段页面已释放。只更新仍存在 post-XDP 程序的第一个描述符的 pagecnt_bias 和碎片。注意仅访问碎片缓冲区的共享信息因为这可避免明显的缓存缺失。xdp_xmit 值仅在 XDP 程序运行时才需要更新并且每个数据包仅更新一次。终止 ice_put_rx_mbuf() 中的 xdp_xmit 指针参数。而是直接在 ice_clean_rx_irq() 函数中设置 xdp_xmit。这样就无需传递参数，也避免了对帧中的每个缓冲区执行额外的按位“或”操作。移动 ntc 本地变量的增量以确保其在对 ice_get_pgcnts() 或 ice_put_rx_mbuf() 的所有调用*之前*更新因为循环逻辑需要当前帧之后紧接着的元素的索引。现在我们使用 ring 中的索引指针来识别数据包因此不再需要跟踪或缓存 rx_ring 中的片段数量。 (CVE-2025-39948)

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

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

  - cryptoaf_alg - 在 af_alg_sendmsg 中及早将合并设置为零如果错误导致 af_alg_sendmsg 中止则 ctx->merge 可能包含之前循环的垃圾值。这样当尝试执行无法执行的合并时可能会在下次登录 af_alg_sendmsg 时触发崩溃。通过在循环开始附近将 ctx->merge 设置为零来修复此问题。 (CVE-2025-39931)

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

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

  - smbclient修复 smbd_negotiate() 错误路径中的 smbdirect_recv_io 泄漏在测试另一个不相关的修补程序期间我能够触发此错误对象剩余在 __kmem_cache_shutdown() 上 (CVE-2025-39929)

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

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

  - octeontx2-pf修复 otx2_sync_tstamp() 中的释放后使用缺陷原始代码依赖 otx2_ptp_destroy() 中的 cancel_delayed_work()这不会确保延迟的工作项目 synctstamp_work 在已在运行的情况下完全完成。这会导致释放后使用情形其中 otx2_ptp 由 otx2_ptp_destroy() 取消分配而 synctstamp_work 仍处于活动状态并尝试取消引用 otx2_sync_tstamp() 中的 otx2_ptp。此外如果 synctstamp_work 是循环型则触发该缺陷的可能性不可忽略。一个典型的争用条件如下所示： CPU 0清理| CPU 1延迟工作回调 otx2_remove() | otx2_ptp_destroy() | otx2_ptp_destroy() () | otx2_sync_tstamp() cancel_delayed_work() | otx2_sync_tstamp() kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF 此项由 KASAN 报告确认 BUG
    KASAN任务 bash/136 在地址 ffff88800aa09a18 的 __run_timer_base.part.0+0x7d7/0x8c0 写入中发生大小为 8 的 slab-use-after-free ... 调用跟踪 <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>... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_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 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 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() 以确保在 otx2_ptp 释放之前正确取消延迟工作项目。最初通过静态分析发现此缺陷。为了重现并测试该问题，我在 QEMU 中模拟了 OcteonTX2 PCI 设备，并在 otx2_sync_tstamp() 函数中引入了人为的延迟，以增加触发该缺陷的可能性。 (CVE-2025-39944)

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

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

  - net/mlx5e强化上行链路 netdev 访问以防止设备取消绑定 函数 mlx5_uplink_netdev_get() 从 mdev->mlx5e_res.uplink_netdev 获取上行链路 netdevice 指针。但是当与 mlx5_core.eth 驱动程序取消绑定时可删除网络设备并清除其指针。这会产生空指针从而造成内核错误。BUG无法处理地址的页面错误0000000000001300 at RIP
    0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: <TASK> mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60 /0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b /0x53 使用前通过检查指针是否为空确保指针有效。如果有效则立即调用 netdev_hold() 以进行引用并防止释放正在使用的网络设备。 (CVE-2025-39947)

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

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

  - dm-stripe: 修复可能的整数溢出 如果区块大小过大stripe_io_hints 中可能存在整数溢出。测试溢出是否发生如果发生则不要设置 limits->io_min 和 limits->io_opt (CVE-2025-39940)

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

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

  - ksmbdsmbdirect验证剩余_数据_长度遵守 max_fragmented_recv_size 这是受到 data_offset + data_length 检查的启发。 (CVE-2025-39942)

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

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

  - qed不收集过多保护替代 GRC 元素在保护替代转储路径中固件可返回过多 GRC 元素导致尝试写入超过之前 kmalloc'ed 转储缓冲区的末尾。这将导致内核恐慌原因是:BUG无法处理 ADDRESS 处的内核分页请求其中 ADDRESS 刚好超过保护替代转储缓冲区的末尾。缓冲区的起始地址为
    p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf 和缓冲区大小为相同数据结构中的 buf_size。The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [ qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] ffffffffc068fa8f 上的 qed_dbg_feature [qed] ffffffffc0690211 中的 qed_dbg_all_data [qed] ffffffffc069798a 中的 qed_fw_fatal_reporter_dump [qed] ffffffff8aa95e51 中的 devlink_safe_report 是 ffffffff8aa9e19 d_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the固件的返回值变为固件应返回的最大合法元素数。 (CVE-2025-39949)

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

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

  - 在 6.5.6之前的 fetchmail 版本中SMTP 客户端在畸形上下文中收到 334 状态代码后进行身份验证时可能崩溃。 (CVE-2025-61962)

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

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

  - cgroup将 cgroup_destroy_wq 拆分为 3 个工作队列当 systemd.unified_cgroup_hierarchy=1 时重复挂载/卸载 perf_event 和 net_prio 控制器时在 LTP cgroup 测试期间 [1] 会发生挂起任务。挂起在破坏根期间在 cgroup_lock_and_drain_offline() 中体现。相关案例 cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio 调用跟踪
    cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root销毁排队 // cgroup_destroy_wq // 终止所有 perf_event css // 一个 perf_event css A 正在终止 // css A 离线排队 cgroup_destroy_wq // 根销毁将首先执行 css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // 一些 perf 子孙将终止 // cgroup_destroy_wq max_active = 1 // 等待 css A 终止 问题场景1. CPU0 挂载 perf_event (rebind_subsystems) 2. CPU1 卸载 net_prio (cgroup_kill_sb)使根销毁工作排队 3. 终止的 perf_event CSS 在根破坏后排队等待离线 4. 根销毁等待用于离线完成但离线工作在 cgroup_destroy 中的根销毁背后受阻_wq (max_active=1) 解决方案：将 cgroup_destroy_wq 拆分为三个专用工作队列cgroup_offline_wq 处理 CSS 脱机操作 cgroup_release_wq 管理资源释放 cgroup_free_wq 执行最终内存解除分配 这种分离消除了等待脱机操作完成时 CSS 释放路径中的阻塞。 [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers (CVE-2025-39953)

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

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

  - net/tcp修复了使用带有 TCP_REPAIR 的 TCP-AO 时的空指针取消引用。在已添加 TCP-AO 密钥且启用了 TCP_REPAIR 的套接字上进行 connect() 系统调用期间tcp_ao_finish_connect() 中可能发生空指针取消引用。在 skb 为空的情况下调用该函数并在事先未进行 skb 验证的情况下尝试在 tcp_hdr(skb)->seq 上取消引用该函数。通过在取消引用 skb 之前检查其是否为空来修复此问题。此注释摘自 bpf_skops_established()其也在同一流程中被调用。与 正在修补的函数不同bpf_skops_established() 会在取消引用 skb 之前对其进行验证。 int main(void){ struct sockaddr_in sockaddr; struct tcp_ao_add tcp_ao int sk int one = 1;
    memset(&sockaddr,'\0',sizeof(sockaddr)); memset(&tcp_ao,'\0',sizeof(tcp_ao)); sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr.sin_family = AF_INET; memcpy(tcp_ao.alg_name,cmac(aes128),12);
    memcpy(tcp_ao.key,ABCDEFGHABCDEFGH,16); tcp_ao.keylen = 16;
    memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, sizeof(tcp_ao)); setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); sockaddr.sin_family = AF_INET; sockaddr.sin_port = htobe16(123); inet_aton(127.0.0.1、 &sockaddr.sin_addr); connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0 } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG内核空指针取消引用地址00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI 硬件名称VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182) (CVE-2025-39950)

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

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

  - drmbridgeanx7625修复早期 IRQ 的空指针取消引用 如果在资源初始化完成之前发生中断则中断处理程序/工作线程可能访问未初始化的数据例如 I2C tcpc_client 设备从而可能导致空指针取消引用。 (CVE-2025-39934)

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

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

  - smb客户端让 recv_done 验证 data_offset、data_length 和剩余数据长度 这是受到相关服务器补丁的启发。 (CVE-2025-39933)

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

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

  - netrfkillgpio修复了由于提交 7d5e9737efda 以来的取消引用未初始化指针造成的崩溃 (net
    rfkillgpio从设备属性中获取名称和类型rfkill_find_type() 使用可能未初始化的 const char *type_name 进行调用本地变量。在 x86 系统上当 rfkill-gpio 绑定至 BCM4752 或 LNV4752 acpi_device 时将根据 ACPI acpi_device_id 设置 rfkill->type = (unsigned)id->driver_data且不存在类型属性device_property_read_string() 将失败并且 type_name 处于未初始化状态从而可能导致崩溃。 rfkill_find_type() 接受空指针通过将 type_name 初始化为 NULL 来修复潜在崩溃。请注意目前尚未捕获此问题可能因为: 1. 没有多少 x86 计算机真正拥有 BCM4752/LNV4752 acpi_device 2. 存储 type_name 的堆栈刚好包含空值 (CVE-2025-39937)

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

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

  - ASoCqcomq6apm-lpass-dais修复源图表失败时的空指针取消引用如果之前打开源图表失败例如 ADSP 因 audioreach 拓扑结构不正确而拒绝图表将关闭并生成 dai_data->graph[dai-> id] 被分配了 NULL。仍在继续为接收器图表准备 DAI但下次对 q6apm_lpass_dai_prepare() 的调用会收到 dai_data->graph[dai->id]=NULL 导致空指针异常qcom-apm gprsvc:service:2:1错误 (1) 处理0x01001002 cmd qcom-apm gprsvc:service:2:1
    DSP 返回错误[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais无法启动 APM 端口 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@ 1:bedaisASoCTX_CODEC_DMA_TX_3 上的 snd_soc_pcm_dai_prepare 发生错误-22 无法处理虚拟地址 00000000000000a8 处的内核空指针取消引用 ... 调用跟踪q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108__soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0 () [] [CVE-2025-39938[]  ]

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

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

  - wifiwilc1000避免 WID 字符串配置中的缓冲区溢出 修复 Smatch 检查程序识别的以下复制溢出警告。 drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() 错误“__memcpy()”“cfg->s[i]->str”复制溢出512 与 65537此修补程序在访问内存缓冲区。检查基于从 固件接收的数据的 WID 类型。对于 WID 字符串配置大小限制由“struct wilc_cfg_str”的“len”字段中维护的“struct wilc_cfg_str_vals”中单个元素的大小确定。
    (CVE-2025-39952)

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

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

  - 该模块将解析不是结构节点子级的 <pattern> 节点。节点将在创建后删除但之后可能会被访问导致释放后使用。 (CVE-2025-10729)

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

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

  - 模块渲染包含 <pattern> 元素的 Svg 文件时可能最终以递归方式渲染该文件从而导致堆栈溢出 DoS (CVE-2025-10728)

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

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

  - scsiqla2xxx修复 I/O 中止超时时发生的崩溃。执行 CPU 热插拔时，发现以下堆栈导致的崩溃。调用跟踪qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166 /0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610
    __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60
    __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160
    __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O 已完成。在尝试完成之前验证 I/O 和中止请求确实未完成。
    (CVE-2022-50493)

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

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

  - wifiath11k修复 WMI 固件 stats 中的内存泄漏 rmmod 期间未释放为固件 pdev、vdev 和 beacon 统计数据分配的内存。通过在硬件取消注册之前调用 ath11k_fw_stats_free() 函数修复此问题。同时避免在处理在 WMI 事件中收到的固件状态时调用 ath11k_fw_stats_free()因为本地列表正在进行拼接和重新初始化因此拼接之后列表中不存在任何元素。测试于：QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 (CVE-2023-53602)

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

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

  - IB/mad不调用在 atomic 上下文中可能会休眠的函数 不允许跟踪点休眠因此会因在 atomic 上下文中调用 ib_query_pkey() 而生成以下 splat。警告：
    CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm
    kworker/u9:0 Kdump 已加载 TaintedG OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 硬件名称Red Hat KVM BIOS 1.13.0-2. module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI
    ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15:
    0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS:0010 DS:
    0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]
    __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[结束跟踪 78ba8509d3830a16 ]--- (CVE-2022-50472)

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

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

  - scsiqla2xxx避免 fcport 指针取消引用 Klocwork 报告的可取消引用空指针的警告。当 sa_ctl 为空并且在退出调用后分配 fcport时例程退出从而导致在退出时取消引用空 fcport 指针。为避免 fcport 指针取消引用请在 sa_ctl 为空时退出例程。 (CVE-2023-53603)

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

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

  - driversbase当取消注册设备时释放 devm 资源 在当前代码中如果设备具有总线并且已被探测则仅 devres_release_all() 才会被调用。这会在使用无总线或无驱动程序的设备时导致一些问题其中如果托管资源持有对设备的引用则设备可能永远不会被释放。例如，DRM 框架中会发生这种情况。因此我们应该在 device_del() 函数中调用 devres_release_all()以确保在设备未注册时即使该设备既没有总线也没有驱动程序也能正确执行设备管理的操作。这实际上与提交 2f8d16a996dadevres释放 device_del() 上的资源相同的更改因内存泄漏问题而被提交 a525a3ddeaca驱动程序核心释放 device_release 中的 devres还原。此修补程序有效结合了上述两个提交以释放 device_del() 和 device_release() 上的资源达到两全其美的效果。 (CVE-2023-53596)

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

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

  - cpufreqdavinci修复 clk 释放后使用 remove 函数会首先释放 clk然后才调用 cpufreq_unregister_driver()。如果就在 cpufreq_unregister_driver() 运行之前调用 cpufreq 回调之一则可能会使用已释放的 clks。 (CVE-2023-53544)

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

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

  - RDMA/rxe修复 rxe_requester 中不完整的状态保存。如果发送数据包被 rxe_requester() 中的 IP 层丢弃则对 rxe_xmit_packet() 的调用可能因 err == -EAGAIN 而失败。为了恢复wqe 的状态会恢复到发送数据包之前的状态以便可以重新发送。但是，保存和恢复状态的例程缺少 wqe 中变量状态的重要部分即用于通过 sge 表进行处理的 dma 结构。并且在构建会修改 dma 结构的数据包之前未保存状态。在使用快速节点上的许多 QP 向慢速节点发送大型消息的重压测试下发现了数据包丢弃并且重新发送的数据包损坏了因为 dma 结构未还原。此修补程序修复了此行为并允许测试案例成功。 (CVE-2023-53539)

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

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

  - cifs在在超时阈值之后重新连接期间修复 mid 泄漏当状态为 STATUS_IO_TIMEOUT 的响应数量超过指定的阈值 (NUM_STATUS_IO_TIMEOUT) 时我们会重新连接。但是我们不会返回中间值或针对中间值返回的贷项，也不会减少正在进行的请求数量。
    此缺陷可导致 server->in_flight 计数变差并且还会造成 mid 泄漏。此更改将检查移动到以下几行即使从转换标头读取响应 也会对响应进行解密。这样就可以重用用于返回 mid 的代码。此外cifs_reconnect 之前只重新连接了传输连接。如果是多通道，这可能不是我们在多次超时后想要做的。对其进行了更改以也重新连接会话和树。
    还将 NUM_STATUS_IO_TIMEOUT 重命名为更合适的名称 MAX_STATUS_IO_TIMEOUT。 (CVE-2023-53597)

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

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

  - drm/amdgpu修复 sdma v4 sw fini 错误修复 sdma 的 sdma v4 sw fini 错误 4.2.2 以解决以下一般保护错误 [ +0.108196] 一般保护错误可能针对非规范地址 0xd5e5a4ae79d24a320000 [#1] PREEMPT SMP PTI [ +0.000018] RIP0010:free_fw_priv+0xd/0x70 [ +0.000022] 调用跟踪[ +0.000012] <TASK> [ +0.000011] release_firmware+0x55/0x80 [ +0.000021] amdgpu_ucode_release+0x11 /0x20 [amdgpu] [ +0.000415] amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu] [+0.000360] sdma_v4_0_sw_fini+0xce/0x110 [amdgpu] (CVE-2023-53547)

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

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

  - drm/amd修复潜在的内存泄漏 此修补程序修复了函数运行到最后一个返回 NULL 时的潜在内存泄漏 (clk_src)。 s/free/kfree/ - Alex (CVE-2022-50479)

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

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

  - btrfs在 push_node_left 中插入 tree mod 日志移动。在 tree mod 日志倒带中存在相当不可能的争用条件可导致内核错误其具有下列跟踪[530.569] BTRFS 危急设备 sda3无法找到逻辑0 长度 4096 [530.585] BTRFS 危急设备 sda3无法找到逻辑 0 长度 4096 [530.602] 缺陷内核空指针取消引用地址0000000000000002 [530.618] #PF内核模式下的主管读取访问 [530.629] #PF: error_code(0x0000) - not-present 页面 [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: under Kdump受感染
    GSOK 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] 硬件名称Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA、BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/ 0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX
    ffff888292e41000 RCXf2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI
    ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14:
     R150000000000001000  : ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2:
    0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1:
    0000000000000000 DR20000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 [530.928] 调用跟踪[530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve+0finx_direct/ [531.076] ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 当逻辑 inode 解析采用 tree mod 日志序列号然后在 backref 遍历时发生忙碌节点上的倒带时会发生此问题。具有以下树状结构 mod 日志操作序列数字已根据特定示例填写但在一定程度上是任意的 REMOVE_WHILE_FREEING 插槽 532 REMOVE_WHILE_FREEING 插槽 531 REMOVE_WHILE_FREEING 插槽 530 ... REMOVE_WHILE_FREEING 插槽 0 移除插槽 455 移除插槽 454 移除插槽 453 ... REMOVE 插槽 0 ADD 插槽 455 ADD 插槽 454 ADD 插槽 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... 删除插槽 0 通过 btrfs_tree_mod_log_rewind 应用此序列时会分配新的 rewind eb并首先插入 533 个元素的正确密钥信息然后覆盖它们的前 456 个通过添加操作将计数减少 456然后通过执行 456:988->0:532之间的内存移动来倒带移动。从未写入过 532 之后的任何内容 ---truncated--- (CVE-2023-53538)

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

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

  - ubifsubifs_releasepage删除 ubifs_assert(0) 使此进程有效 ubifs 写入页面有两种状态1. 脏、私有 2. 非脏、非私有 正常进程无法转至 ubifs_releasepage()即存在页面正在写入隐私但不脏。Re Producer [1] 表明此问题可能与 [2] 相关通过以下进程发生 PA PB PC lock(page)[PA] ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirty unlock(page) write_cache_pages[PA] ] lock(page) clear_page_dirty_for_io(page) // 清除脏 ubifs_writepage do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0 i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page ->index > end_index) goto out // 跳出
    unlock(page) // 私有、非脏 generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // 错误的断言unlock(page) truncate_pagecache[PB] 然后我们可能得到以下 assertion failed: UBIFS 错误 (ubi0:0 pid 1683):
    ubifs_assert_failed [ubifs] UBIFS 断言失败fs/ubifs/file.c:1513 UBIFS 警告 (ubi0:0 pid 1683)ubifs_ro_mode [ubifs]切换至只读模式错误 -22 CPU2 PID 1683 Commaa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 调用跟踪dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0[ ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215373 [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty2CVE-2023-53584

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

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

  - netdevsim修复 nsim_dev_resources_register() 失败时 nsim_drv_probe() 中的内存泄漏。如果 nsim_dev_resources_register() 中的某些项目失败将发生内存泄漏。以下是内存泄漏信息。
    未引用的对象 0xffff888074c02600（大小 128）：comm echo，pid 8159，jiffies 4294945184（使用期限 493.530s）十六进制转储前 32 字节：40 47 ea 89 ff ff ff ff ff 01 00 00 00 00 00 00 00 @G... ............ ff ff ff ff ff ff ff ff ff ff ff ff ff ff<0000000011a31c98>ff ff ff ff .. +0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] real_probe+0x20b/0xb10 [<00000000c416848a>]
    __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>]
    __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>]
    __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x1606/0x1606/0x1606 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80 (CVE-2022-50500)

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

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

  - gpiomvebu修复 irq 域泄漏 Uwe Kleine-Knig 指出 mvebu 驱动程序中仍然存在一个在驱动程序分离时触发的一个资源泄漏问题。让我们通过自定义 devm 操作来解决该问题。 (CVE-2023-53579)

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

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

  - wifimac80211首先在客户端探测中检查站点当探测客户端时首先检查是否有站点然后检查通道上下文否则您可在 AP 甚至都没有启动的情况下通过探测轻松触发警告还没有。由于存在客户端意味着 AP 也在运行因此我们可以保留警告。还可稍微简化移动的代码。 (CVE-2023-53588)

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

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

  - bpf、cpumap在映射更新返回之前确保 kthread 正在运行当运行启用了压力模式的 xdp_redirect_cpu 时包含一些 RT 线程时报告了以下警告------------[cut here]--- --------- WARNINGCPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 6.5.0-rc2+ 未受感染 #1 硬件名称QEMU Standard PC(i440FX + PIIX,1996) Workqueue事件 cpu_map_kthread_stop RIP0010:put_cpu_map_entry+0xda/0x220 ...... 调用跟踪 <TASK> ? show_regs+0x65/0x70 __warn+0xa5/0x240 ...... put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The root cause is the same as commit 436901649731 (bpf: cpumap修复 cpu_map_update_elem 中的内存泄漏。kthread 在 cpu_map_kthread_stop() 中被 kthread_stop() 提前停止kthread() 根本不调用 cpu_map_kthread_run()但 XDP 程序已将某些帧或 skbs 排入 ptr_ring 队列。因此当 __cpu_map_ring_cleanup() 检查 ptr_ring 时会发现其未清空并报告警告。替代补丁是使用
    __cpu_map_ring_cleanup() 以在 kthread_stop() 返回 -EINTR 时放弃这些待定帧或 skb但可能会使用户混淆因为 XDP 程序已正确处理这些帧或 skb。因此不必丢弃这些帧或 skb而只需确保之前每个 cpu 的 kthread 正在运行即可
    __cpu_map_entry_alloc() 返回。应用此补丁之后将不再需要 kthread_stop() 的错误句柄因为它将始终返回 0因此只需将其删除。 (CVE-2023-53577)

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

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

  - wifiiwlwifimvm在 iwl_mvm_sec_key_add() 中验证 key_len 大小时有必要修复 IWL_SEC_WEP_KEY_OFFSET 潜在的数组越界访问帐户问题。 (CVE-2023-53575)

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

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

  - drm/msm修复探测延迟上的释放后使用桥计数器拆卸 DRM 设备时从未重置以便在下次拆卸时访问已释放结构的过时指针例如
    在第二次延迟绑定之后。考虑到足够的桥接和一些探测延迟这目前还可能导致损坏桥接阵列以外的数据。patchwork
    https://patchwork.freedesktop.org/patch/502665/ (CVE-2022-50492)

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

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

  - wificfg80211拒绝认证/关联到使用我们公司地址的 AP 如果 AP 使用我们公司地址作为其 MLD 地址或 BSSID则显然出现了问题。拒绝此类连接以免我们稍后尝试失败。
    (CVE-2023-53540)

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

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

  - 驱动程序核心修复 device_add() 中的资源泄漏当调用 device_add() 中的 kobject_add() 失败时它将调用 cleanup_glue_dir() 以释放资源。但在 kobject_add() 中dev->kobj.parent 已被设置为 NULL。
    这将导致资源泄漏。进程如下 device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //失败, 但 set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, 并转到 //错误标签 ... cleanup_glue_dir() //因为glue_dir 为空不是调用 //kobject_put() 前述问题可能造成 insmod mac80211_hwsim.ko 失败。 sysfs无法创建重复文件名 '/devices/virtual/mac80211_hwsim' 调用跟踪 <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x3_ddeviceparent/0x170/ 0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140 /0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> 具有 -EEXIST 的 mac80211_hwsim 的 kobject_add_internal 失败请勿尝试在相同目录中使用相同名称注册事物。
    (CVE-2023-53594)

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

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

  - wifirtw88通过删除“rtw_core_deinit()”中的 TX 清除定时器和释放 C2H 队列卸载时删除定时器并释放 skb 队列通过释放 COEX 队列来缩小后者的关键部分TX 报告锁定范围。 (CVE-2023-53574)

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

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

  - drm/msm修复绑定错误时的 vram 泄漏确保也在子组件绑定失败的情况下释放 VRAM 缓冲区。Patchwork https://patchwork.freedesktop.org/patch/525094/ (CVE-2023-53562)

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

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

  - rcu-tasks避免在 cblist_init_generic() 中使用旋转锁 pr_info() 在 rtp->cbs_gbl_lock 旋转锁锁定的情况下调用 pr_info()。由于 pr_info() 调用可能休眠的 printk()这将导致如下所示的缺陷 [ 0.206455] cblist_init_generic设置可调整数量的回调队列。 [ 0.206463] [ 0.206464] ============================= [ 0.206464] [ BUG无效的等待上下文 ] [ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 未受感染 [ 0.206466] ----------------------------- [ 0.206466] swapper/0/1 正在尝试锁定[ 0.206467] fffffffffa0167a58 (&port_lock_key){....}-{3:3}at
    serial8250_console_write+0x327/0x4a0 [ 0.206473] 其他可能帮助我们调试此问题的信息 [ 0.206473] context-{5:5} [ 0.206474] swapper/0/1 保留的锁 [ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}位于 cblist_init_generic.constprop.0+0x14/0x1f0 [ 0.206478] #1
    ffffffff9eb579c0 (console_lock){+.+.}-{0:0}网址是 _printk+0x63/0x7e [ 0.206482] #2ffffffff9ea77780 (console_owner){....}-{0:0}网址是 console_emit_next_record。 constprop.0+0x111/0x330 [ 0.206485] stack backtrace[ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5 [ 0.206488] 硬件名称QEMU Standard PC i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 [ 0.206489] 调用跟踪[ 0.206490] <TASK> [ 0.206491] dump_stack_lvl+0x6a/0x9f [ 0.206493] __lock_acquire.cold +0x2d7/0x2fe [ 0.206496] ? stack_trace_save+0x46/0x70 [ 0.206497] lock_acquire+0xd1/0x2f0 [ 0.206499] ? serial8250_console_write+0x327/0x4a0 [ 0.206500] ? __lock_acquire+0x5c7/0x2720 [ 0.206502]
    _raw_spin_lock_irqsave+0x3d/0x90 [ 0.206504] ? serial8250_console_write+0x327/0x4a0 [ 0.206506] serial8250_console_write+0x327/0x4a0 [ 0.206508] console_emit_next_record.constprop.0+0x180/0x330 [0.206511] console_unlock+0xf7/0x1f0 [ 0.206512] vprintk_emit+0xf7/0x330 0.206514_printk [] +0x63/0x7e [0.206516] cblist_init_generic.constprop.0.cold+0x24/0x32 [ 0.206518] rcu_init_tasks_generic+0x5/0xd9 [0.206522] kernel_init_freeable+0x15b/0x2a2 [ 0.206523] ? rest_init+0x160/0x160 [ 0.206526] kernel_init+0x11/0x120 [ 0.206527] ret_from_fork+0x1f/0x30 [ 0.206530] </TASK> [ 0.207018] cblist_init_generic将 shift 设置为 1将 lim 设置为 1。此修补程序移动 pr_info()这样在不锁定 rtp->cbs_gbl_lock 的情况下调用它。 (CVE-2023-53558)

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

ID	名称	严重性
269463	Linux Distros 未修补的漏洞：CVE-2025-46817	critical
269462	Linux Distros 未修补的漏洞：CVE-2025-46818	high
269461	Linux Distros 未修补的漏洞：CVE-2025-11234	high
269460	Linux Distros 未修补的漏洞：CVE-2025-46819	high
269459	Linux Distros 未修补的漏洞：CVE-2025-39932	medium
269458	Linux Distros 未修补的漏洞：CVE-2025-39951	medium
269457	Linux Distros 未修补的漏洞：CVE-2025-39946	medium
269456	Linux Distros 未修补的漏洞：CVE-2025-39943	critical
269455	Linux Distros 未修补的漏洞：CVE-2025-39945	high
269454	Linux Distros 未修补的漏洞：CVE-2025-39948	medium
269453	Linux Distros 未修补的漏洞：CVE-2025-39931	medium
269452	Linux Distros 未修补的漏洞：CVE-2025-39929	medium
269451	Linux Distros 未修补的漏洞：CVE-2025-39944	high
269450	Linux Distros 未修补的漏洞：CVE-2025-39947	medium
269449	Linux Distros 未修补的漏洞：CVE-2025-39940	medium
269448	Linux Distros 未修补的漏洞：CVE-2025-39942	medium
269447	Linux Distros 未修补的漏洞：CVE-2025-39949	medium
269446	Linux Distros 未修补的漏洞：CVE-2025-61962	medium
269445	Linux Distros 未修补的漏洞：CVE-2025-39953	medium
269444	Linux Distros 未修补的漏洞：CVE-2025-39950	medium
269443	Linux Distros 未修补的漏洞：CVE-2025-39934	medium
269442	Linux Distros 未修补的漏洞：CVE-2025-39933	medium
269441	Linux Distros 未修补的漏洞：CVE-2025-39937	medium
269440	Linux Distros 未修补的漏洞：CVE-2025-39938	medium
269439	Linux Distros 未修补的漏洞：CVE-2025-39952	high
269438	Linux Distros 未修补的漏洞：CVE-2025-10729	critical
269437	Linux Distros 未修补的漏洞：CVE-2025-10728	critical
269436	Linux Distros 未修补的漏洞：CVE-2022-50493	medium
269435	Linux Distros 未修补的漏洞：CVE-2023-53602	medium
269434	Linux Distros 未修补的漏洞：CVE-2022-50472	high
269433	Linux Distros 未修补的漏洞：CVE-2023-53603	medium
269432	Linux Distros 未修补的漏洞：CVE-2023-53596	high
269431	Linux Distros 未修补的漏洞：CVE-2023-53544	high
269430	Linux Distros 未修补的漏洞：CVE-2023-53539	medium
269429	Linux Distros 未修补的漏洞：CVE-2023-53597	low
269428	Linux Distros 未修补的漏洞：CVE-2023-53547	medium
269427	Linux Distros 未修补的漏洞：CVE-2022-50479	medium
269426	Linux Distros 未修补的漏洞：CVE-2023-53538	medium
269425	Linux Distros 未修补的漏洞：CVE-2023-53584	medium
269424	Linux Distros 未修补的漏洞：CVE-2022-50500	medium
269423	Linux Distros 未修补的漏洞：CVE-2023-53579	medium
269422	Linux Distros 未修补的漏洞：CVE-2023-53588	high
269421	Linux Distros 未修补的漏洞：CVE-2023-53577	medium
269420	Linux Distros 未修补的漏洞：CVE-2023-53575	high
269419	Linux Distros 未修补的漏洞：CVE-2022-50492	high
269418	Linux Distros 未修补的漏洞：CVE-2023-53540	medium
269417	Linux Distros 未修补的漏洞：CVE-2023-53594	medium
269416	Linux Distros 未修补的漏洞：CVE-2023-53574	medium
269415	Linux Distros 未修补的漏洞：CVE-2023-53562	medium
269414	Linux Distros 未修补的漏洞：CVE-2023-53558	medium

检测

Nessus 的 Misc. 系列

critical

high

high

high

medium

medium

medium

critical

high

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

critical

critical

medium

medium

high

medium

high

high

medium

low

medium

medium

medium

medium

medium

medium

high

medium

high

high

medium

medium

medium

medium

medium