Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - kprobes：修正排清 kprobe 最佳化工具時的永久懸置 當 kprobe 進行跳轉最佳化時，將 0 寫入 /proc/sys/debug/kprobes-optimization 永遠不會傳回。寫入器永遠處於 D 狀態，並保留kprobe_sysctl_mutex，因此該 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時間表+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/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/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - kprobes:kprobe オプティマイザーのフラッシュ時の恒久的なハングを修正。kprobe がジャンプ最適化されている間に /proc/sys/debug/kprobes-optimization に 0 を書き込むと、戻ってこません。書き込み元は、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スケジュール+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> ... 情報：
    タスク cat:265 は、おそらくタスク sh:246 が所有する mutex でブロックされています。wait_for_kprobe_optimizer_locked() は optimizer_completion を再初期化し、オプティマイザスレッドにフラッシュを要求し、wait_for_completion() 内でスリープ状態になります。スレッドは(未)最適化リストを排出しますが、completion_done()がtrueの場合、つまり完了がすでに完了している場合のみcomplete()を呼び出します。誰かが待機している間は決して発生しません。disarm_all_kprobes() と kprobe_trace_self_tests_init() は同じように待ちます。無条件で complete() を呼び出すだけでは十分ではありません。wait er はスリープ中に kprobe_mutex をドロップし、debugfs が有効なファイルに対して sysctl ハンドラーをシリアル化することはありません。たとえば、無効化されたプローブが非最適化のキューに入っているためなど、リストが空でないことをまだ見つける 2 番目のフラッシャーは、最初の sysctl write 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 がリセットされます、 最初の // waiter がキューから外れています mutex_unlock(&kprobe_mutex) wait_for_completion(c) kprobe_optimizer() complete(c) // c が &optimizer_completion の場合にのみ debugfs writer をウェイクアップします。オプティマイザパス中に2つの書き込みを並べると、このようにしてsysctlライターが失われます。完了をオプティマイザーパスのカウンターに置き換えます。各パスの終わりにぶつかり、wake_up_var_locked() で示されます(両方ともkprobe_mutex下)。フラッシャーはカウントをサンプリングし、スリープ中にのみkprobe_mutexをドロップする wait_var_event_mutex() で待機します。したがって、新しいカウントはその間にパス全体が実行されたことを意味します。何も再初期化されないため、複数のフラッシュが同時に待機中をスリープできます。(CVE-2026-98530)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - kprobes: Fix permanent hang when flushing the kprobe optimizer Writing 0 to /proc/sys/debug/kprobes-     optimization while a kprobe is jump-optimized never returns. The writer sleeps in D state forever with     kprobe_sysctl_mutex held, so any later read or write of that sysctl hangs as well. For example, with     vfs_read+9 as an optimizable address in this build: # cd /sys/kernel/tracing # echo 'p:myprobe vfs_read+9'     >> kprobe_events # echo 1 > events/kprobes/myprobe/enable # # wait until /sys/kernel/debug/kprobes/list     shows [OPTIMIZED] # echo 0 > /proc/sys/debug/kprobes-optimization INFO: task sh:246 blocked for more than     10 seconds. Call Trace: <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:
    task cat:265 is blocked on a mutex likely owned by task sh:246. wait_for_kprobe_optimizer_locked()     reinitializes optimizer_completion, asks the optimizer thread to flush and sleeps in     wait_for_completion(). The thread drains the (un)optimizing lists, but calls complete() only if     completion_done() is true, i.e. if the completion is already done, which never happens while someone     waits. disarm_all_kprobes() and kprobe_trace_self_tests_init() wait the same way. Calling complete()     unconditionally would not be enough: the waiter drops kprobe_mutex while it sleeps, and nothing else     serializes the sysctl handler against the debugfs enabled file. A second flusher that still finds the     lists non-empty, e.g. because a disabled probe is queued for unoptimizing, reinitializes the completion     under the first: sysctl write debugfs enabled write 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 is reset, the first     // waiter is off the queue mutex_unlock(&kprobe_mutex) wait_for_completion(c) kprobe_optimizer()     complete(c) // wakes the debugfs writer only where c is &optimizer_completion. Lining up the two writes     during an optimizer pass loses the sysctl writer this way. Replace the completion with a counter of     optimizer passes, bumped at the end of each pass and signalled with wake_up_var_locked(), both under     kprobe_mutex. A flusher samples the count and waits with wait_var_event_mutex(), which drops kprobe_mutex     only while sleeping, so a new count means a whole pass ran in the meantime. Nothing is reinitialized, so     several flushers can sleep in the wait at once. (CVE-2026-98530)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
367610	Linux Distros 未修補弱點：CVE-2026-98530	Nessus	Misc.	2026/10/20	2026/10/20	high
367610	Linux Distros 未修补的漏洞：CVE-2026-98530	Nessus	Misc.	2026/10/20	2026/10/20	high
367610	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98530	Nessus	Misc.	2026/10/20	2026/10/20	high
367610	Linux Distros Unpatched Vulnerability : CVE-2026-98530	Nessus	Misc.	2026/10/20	2026/10/20	high

检测

插件搜索

high

high

high

high