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

  - rcu保护 ->defer_qs_iw_pending 免受数据争用在使用 CONFIG_IRQ_WORK=y 构建的内核上在禁用中断禁用的代码区域内调用 rcu_read_unlock() 时 [1] 将调用使用 irq-work 处理程序的 rcu_read_unlock_special()以强制系统在 RCU 读取端关键部分实际结束时发出通知。在最早启用中断之前，这种情况不会发生。在某些内核中例如通过 rcuttree.use_softirq=y 引导的内核会无条件使用 irq-work 处理程序。per-CPU rcu_data 结构的 ->defer_qs_iw_pending 字段由 irq-work 处理程序更新并由 rcu_read_unlock_special() 读取和更新。这导致了以下 KCSAN splat ------------------------------------------ ------------------------------ BUGKCSANrcu_preempt_deferred_qs_handler / rcu_read_unlock_special 中的数据争用任务 90 读取 0xffff96b95f42d8d8 中的 1 个字节在 cpu 8 上rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0
    __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8
    rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq 事件标记200272 hardirqs last启用时间 (200272)
    [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs 上次禁用的时间为 (200271)
    [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs 上次启用的时间为 (0)[<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs 上次禁用的时间为 (0): [<0000000000000000>] 0x0
    -------------------------------------------------- ---------------------- 问题在于 irq-work 处理程序在启用中断的情况下运行这意味着 rcu_preempt_deferred_qs_handler() 可以被中断并且该中断处理程序可能包含 RCU 读取端关键区段其可能调用 rcu_read_unlock_special()。在 RCU 使用的严格 KCSAN 操作模式中这构成 ->defer_qs_iw_pending 字段上的数据争用。因此此提交禁用了 rcu_preempt_deferred_qs_handler() 中用于更新 ->defer_qs_iw_pending 字段的部分的中断。这已足够因为此处理程序不是快速路径。 (CVE-2025-39749)

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

检测

Linux Distros 未修补的漏洞：CVE-2025-39749

high Nessus 插件 ID 264751

版本 1.25