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

  - signal：防止 exec（） 争用 Hyunwoo 调试了以下 KASAN UAF splat：缺陷：KASAN：0xb27__send_signal_locked任务 poc/79 在地址 ffff888007ed80c8 处的 slab-use-after-free：0xba0 ... 调用跟踪：__send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0
    __x64_sys_tgkill+0x193/0x270 ... 按任务 80 分配：do_timer_create+0x1a4/0x1030
    __x64_sys_timer_create+0x145/0x190 ... 由任务 12 释放：kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... 上一次可能相关的工作创建：
    kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 事实证明，这种情况发生在非领导者 exec（） 上，正如 Hyunwoo 所解释的那样：
    de_thread（） 在 release_task（leader） 之前调用 exchange_tids（），因此针对 leader 的 tid 创建的 SIGEV_THREAD_ID 定时器保留的结构 pid 现在指向调用 execve（） 的线程。pid_task（） 返回该线程，lock_task_sighand（） 会成功。如果定时器信号被阻断，其 sigqueue 将在领导者的 task：:p ending 上保持排队状态。然后，该定时器的下一个到期时间可在 release_task（） 刷新队列时运行。posixtimer_send_sigqueue（） 检查 sigqueue 是否已使用仅读取 list_head：：next 的普通 list_empty（） 进行排队。list_del_init（） 不是原子型的，INIT_LIST_HEAD（） 在 list_head：:p rev 之前存储 list_head：：next，因此检查可以在两者之间传递。list_add_tail（） 将实时线程的 task：:p ending 上的条目排队，刷新中的 list_head：:p rev 存储随后覆盖 list_add_tail（） 刚刚设置的 list_head：:p rev 链接。__flush_itimer_signals（） 也不会撤消该操作。当 list_head：:p rev 指向条目本身时，其 list_del_init（） 只会再次存储相同的值，因此不会从列表中删除该条目。它仍然存在于终止最后一个引用且定时器被 RCU 释放之后，并且后续 tgkill（） 的 list_add_tail（） 跟随该 list_head：:p rev 进入释放的定时器。在最近的提交中出现了此问题，该提交将 sigqueue 刷新移出了 sighand 锁定保留的区域。Hyonwoo 提议使用 list_del_init_careful（） 解决此问题，但这只是掩盖了问题。经过一番讨论和各种解决尝试后，Eric 指出没有理由在 release_task（） 中较晚刷新 task：:p ending，应该已经在 exit_signals（） 中完成。由于没有任何东西可以收集和发送在垂死任务的待定队列中排队的信号，因此没有理由进一步延迟它。但必须确保在该点之后，任何信号都不能排队到其中。exit_signals（） 在 task：：flags 中设置PF_EXITING，可用作此情况的指标。通过以下方法解决该问题：- 在 __send_signal_locked（） 和 posixtimer_send_sigqueue（） 中PF_EXITING设置任务时，防止任务隐私信号 （PIDTYPE_PID） 的信号排队。- 保护 exit_signals（） 中针对任务组为空的任务组和具有 sighand 锁定的组退出情况的未锁定的PF_EXITING设置
    - 刷新任务：:p结束信号就在那里。通过将整个待定列表移动到 sighand 锁定下的堆栈上列表头来优化这一点，并在未保留锁定的情况下释放信号。关于弱顺序系统上的无锁刷新和非前导 exec 情况，已经有相当多的讨论。问题在于，尝试发送 posix 定时器信号的第三方依赖 PID 查找来查找目标任务，并且当信号最初定向到旧前导时，该查找可能会生成新的前导者。如果信号在旧前导线上排队，则无锁刷新会引起对以下情况的关注：old_leader new_leader 第三方 A：flush_list（） // list_del_in ---truncated--- （CVE-2026-98256）

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

检测

Linux Distros 未修补的漏洞：CVE-2026-98256

high Nessus 插件 ID 364267

版本 1.3