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

  - kprobes：修复刷新 kprobe 优化器时的永久挂起 当 kprobe 进行跳转优化时，将 0 写入 /proc/sys/debug/kprobes-optimization 永远不会返回。写入器在保留 kprobe_sysctl_mutex 的情况下永远处于 D 状态休眠，因此该 sysctl 的任何后续读取或写入也会挂起。例如，在此版本中使用 vfs_read+9 作为可优化地址：# cd /sys/kernel/tracing # echo 'p：myprobe vfs_read+9' >> kprobe_events # echo 1 > events/kprobes/myprobe/enable # # 等待 /sys/kernel/debug/kprobes/list 显示 [OPTIMIZED] # echo 0 > /proc/sys/debug/kprobes-optimization INFO：任务 sh：246 阻塞超过 10 秒。呼叫跟踪： <TASK> __schedule+0x1176/0x4f70 schedule+0xdc/0x2c0 schedule_timeout+0x17b/0x260 wait_for_completion+0x173/0x3c0 wait_for_kprobe_optimizer_locked+0xbc/0x130 proc_kprobes_optimization_handler+0x156/0x1b0 proc_sys_call_handler+0x324/0x490 vfs_write+0x52d/0xfe0 ksys_write+0xff/0x200 do_syscall_64+0x106/0x630 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ... INFO：
    任务 cat：265 在可能属于任务 sh：246 的互斥体上被阻断。wait_for_kprobe_optimizer_locked（） 重新初始化optimizer_completion，要求优化器线程刷新，并在 wait_for_completion（） 中休眠。线程耗尽（未）优化列表，但仅在 completion_done（） 为 true（） 时调用 complete（），即如果完成已经完成，这在有人等待时永远不会发生。disarm_all_kprobes（） 和 kprobe_trace_self_tests_init（） 以相同的方式等待。无条件调用 complete（） 是不够的：等待程序在其休眠时丢弃 kprobe_mutex，并且没有其他任何东西针对已启用 debugfs 的文件序列化 sysctl 处理程序。第二个刷新器仍然发现列表为非空（例如，因为禁用的探测已排入非优化队列），会在第一个刷新器下重新初始化完成：sysctl 写入 debugfs 启用写入 unoptimize_all_kprobes（） wait_for_kprobe_optimizer_locked（） init_completion（c） mutex_unlock（&kprobe_mutex） wait_for_completion（c） disarm_all_kprobes（） wait_for_kprobe_optimizer_locked（） init_completion（c） // c->wait 被重置， 第一个 // 等待程序不在队列中 mutex_unlock（&kprobe_mutex） wait_for_completion（c） kprobe_optimizer（） complete（c） // 仅在 C 为 &optimizer_completion 时唤醒 debugfs 编写器。在优化器传递期间对齐两次写入会以这种方式丢失 sysctl 写入器。用优化器传递计数器替换完成，在每个传递结束时碰撞并用 wake_up_var_locked（） 发出信号，均在kprobe_mutex下。刷新器对计数进行采样并使用 wait_var_event_mutex（） 等待，后者仅在休眠时下降 kprobe_mutex，因此新的计数表示在此期间运行了整个传递。不会重新初始化任何内容，因此多个刷新器可在等待期间同时休眠。（CVE-2026-98530）

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

检测

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

high Nessus 插件 ID 367610

版本 1.4