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

  - sched_ext：修复核心计划下的 rq->core_pick 损坏 核心计划的 pick_next_task（） 选择在共享的核心范围的 rq 锁定下的单个通道中的核心的每个 SMT 同级上运行什么。只有在持续持有锁定时，选择状态才一致，因此 ->pick_task（） 原本无法释放锁定。但是，由于 4c95380701f5（sched/ext：将 balance_scx（） 包括在 pick_task_scx（）） 中），sched_ext从拾取和调度内部运行调度可能会终止 rq 锁。为支持此功能，已更新 pick_next_task（），以便在释放锁定后当拾取返回RETRY_TASK时重新启动整个选择。当同一核心上的选择通过已终止的锁定交错时，它们会破坏彼此的状态：一个清除另一个的 rq->core_pick从而导致空取消引用，或者使其保留上一个任务决策无效，让已出列的任务继续运行，这会死锁下一次唤醒并匹配报告的硬挂起。SMT 机器上的 Cookied ping-pong 加载使交错更频繁，并在几秒钟内终止内核。通过使拾取在调度释放 rq 锁时返回RETRY_TASK来修复此问题，以便选择仅提交在持续保持的锁定下进行的拾取。上一个修补程序的 rq->scx.lock_drop_seq 对版本进行计数。未接触任何内容的分派永远不会释放锁定，其判定（包括未运行任何内容）有效：重试是有边界的，每次重试都遵循实际执行了某些操作的分派，并且空闲 CPU 不会循环。如果另一个调度已经在 rq 上运行，请跳过调度并从本地已经排队的内容中进行选择 - 正在运行的调度已经释放了锁，因此它自己的选择将重试并重新拾取此 rq，而在此处返回RETRY_TASK只会旋转调度需要完成的锁。平衡回调必须在将它们排队的上下文中运行，因此它们只能在 CPU 自己的 rq 上排队。为其他 rq 调度时，请改为直接运行延迟工作 - 该 rq 可能会通过 core-sched 快速路径消耗其所有选择，而且永远不会自行排队回调。关于留下可运行任务的 put_prev_task_scx（） 警告，假定该 dispatch 作为正在切换的 pick 的一部分运行。这现在仅在非核心路径上成立，因此将其保护并从其条件中终止 cookie-match 测试，该测试在没有核心计划的情况下始终成立。
    (CVE-2026-89517)

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

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

  - sched_ext：修正核心排程下的 rq->core_pick 損毀 核心排程的 pick_next_task（） 會在共用核心範圍的 rq 鎖定下，在單一傳遞中選擇要在核心的每個 SMT 同級上執行的內容。只有在連續持有鎖定時，選擇狀態才一致，因此 ->pick_task（） 原本無法釋放它。但是，由於 4c95380701f5 （sched/ext：將 balance_scx（） 折疊成 pick_task_scx（）），sched_ext從拾取和分派內部執行分派可能會刪除 rq 鎖定。為了支援這一點，pick_next_task（） 已更新，以便在釋放鎖定後，當揀選返回RETRY_TASK時重新啟動整個選擇。當同一核心上的選擇透過丟棄的鎖定交錯時，它們會破壞彼此的狀態：一個清除另一個的 rq->core_pick 導致 NULL 解除參照，或使其保留上一個任務決策失效，使出隊任務繼續執行，這會使下一次喚醒鎖死並匹配報告的硬懸置。SMT 機器上的 cookie 乒乓加載會使交錯頻繁，並在幾秒鐘內殺死核心。透過在分派釋放 rq 鎖定時使選擇返回RETRY_TASK來修正它，以便選擇僅提交在持續保留鎖定下進行的選擇。上一個修補程式的 rq->scx.lock_drop_seq 會計算版本。未觸及任何內容的分派永遠不會釋放鎖定，其判定（包括任何要執行的內容）都有效：重試是有限制的，每次重試都遵循實際執行某些動作的分派，並且閒置的 CPU 不會迴圈。如果另一個分派已經在 rq 上進行中，請跳過分派並從本機已排入佇列的內容中挑選 - 正在進行的分派已釋放鎖定，因此它自己的選擇將重試並重新挑選此 rq，而在此處返回RETRY_TASK只會在分派需要完成的鎖定上旋轉。平衡回呼必須在將其排入佇列的內容中執行，因此它們只能在 CPU 自己的 rq 上排入佇列。針對另一個 rq 分派時，請改為直接執行延遲的工作 - 該 rq 可能會透過核心排程快速路徑耗用其所有選擇，並且永遠不會將回呼本身排入佇列。關於可執行任務被遺忘的 put_prev_task_scx（） 警告假設分派作為正在切換的選擇的一部分運行。現在它只適用於非核心路徑，因此請將其門控並從其條件中刪除 cookie-match 測試，該測試在沒有核心調度的情況下始終為真。
    (CVE-2026-89517)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - sched_ext:コアスケジューリングの rq->core_pick 破損を修正します。コアスケジューリングの pick_next_task() は共有コア全体の rq ロックの下で、単一パスでコアの SMT 兄弟すべてで何を実行するかを選択します。選択状態はロックが連続的に保持されている場合にのみ一貫するため、->pick_task() はもともとロックを解除できませんでした。ただし、4c95380701f5(sched/ext:balance_scx() を pick_task_scx() に格納)以降、ピックとディスパッチの内側からsched_ext実行すると、rq ロックがドロップされる可能性があります。これをサポートするために、ロックを解放した後にピックがRETRY_TASKを戻すと選択全体が再起動するように pick_next_task() が更新されました。同じコア上の選択がドロップされたロックを通過してインターリーブされると、それらは互いの状態を破損します。一方は他方の rq->core_pick をクリアして NULL デリファレンスを引き起こしたり、またはその keep-the-preepious-task 決定を無効にしてキューから外されたタスクを実行されたまま放置します。これにより、次のウェイクアップでデッドロックが発生し、報告されたハードハングが一致します。SMT マシンでクッキー化されたピンポンをロードすると、インターリーブが頻繁に発生し、数秒でカーネルが強制終了されます。ディスパッチが rq ロックをリリースするたびにピックがRETRY_TASKを返すことでこれを修正し、連続的に保持されているロックの下で行われたピックのみが選択がコミットされるようにします。前のパッチの rq->scx.lock_drop_seq はリリースをカウントします。何も触れなかったディスパッチはロックを決して解放せず、実行するものが何も含まれて、その判定は成り立つ:リトライはバインドされ、それぞれが実際に何かを行ったディスパッチに続いて行われるため、アイドル状態の CPU はループしません。別のディスパッチが rq で既に実行中の場合は、ディスパッチをスキップし、ローカルですでにキューイングされているものからピッキングします。インフライトディスパッチはロックを解放しているため、それ自体の選択がこの rq を再試行して再ピックしますが、ここでRETRY_TASKを返すと、ディスパッチが完了する必要があるロックでのみスピンします。バランスコールバックは、キューに入れたコンテキストで実行する必要があるため、CPU 自身の rq でのみキューに入れることができます。別の rq にディスパッチする場合、代わりに延期作業を直接実行してください - その rq は、core-sched ファストパスを通じてすべてのピックを消費し、コールバック自体をキューイングすることはありません。実行可能なタスクが取り残されることに関する put_prev_task_scx() 警告は、ディスパッチがスイッチアウェイするピックそのものの一部として実行されることを前提としています。これは今では非コアパスでのみ保持されるため、ゲートして、コアスケジューリングなしで常に true である cookie-match テストをその状態からドロップします。
    (CVE-2026-89517)

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

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

  - sched_ext: Fix rq->core_pick corruption under core scheduling Core scheduling's pick_next_task() picks     what to run on every SMT sibling of the core in a single pass under the shared core-wide rq lock. The     selection state is consistent only while the lock is held continuously, so ->pick_task() originally could     not release it. However, since 4c95380701f5 (sched/ext: Fold balance_scx() into pick_task_scx()),     sched_ext runs dispatch from inside the pick and dispatching can drop the rq lock. To support this,     pick_next_task() has been updated to restart the whole selection when a pick returns RETRY_TASK after     releasing the lock. When selections on the same core interleave through the dropped lock, they corrupt     each other's state: one clears the other's rq->core_pick leading to a NULL deref, or invalidates its keep-     the-previous-task decision leaving a dequeued task running, which deadlocks the next wakeup and matches     the reported hard hangs. A cookied ping-pong load on an SMT machine makes the interleavings frequent and     kills the kernel within seconds. Fix it by making the pick return RETRY_TASK whenever dispatch released     the rq lock, so that a selection only ever commits picks made under a continuously held lock. The previous     patch's rq->scx.lock_drop_seq counts the releases. A dispatch that touched nothing never releases the lock     and its verdict, including nothing to run, stands: retries are bounded, each following a dispatch that     actually did something, and an idle CPU does not loop. If another dispatch is already in flight on the rq,     skip dispatching and pick from what is already queued locally - the in-flight dispatch has released the     lock, so its own selection will retry and re-pick this rq, while returning RETRY_TASK here would only spin     on the lock that dispatch needs to finish. Balance callbacks must run in the context that queued them, so     they can only be queued on the CPU's own rq. When dispatching for another rq, run the deferred work     directly instead - that rq may consume all its picks through the core-sched fast path and never queue the     callback itself. The put_prev_task_scx() warning about a runnable task being left behind assumed that     dispatch ran as part of the very pick that is switching away. That now only holds on the non-core path, so     gate it and drop the cookie-match test, which is always true without core scheduling, from its condition.
    (CVE-2026-89517)

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

ID	Name	Product	Family	Published	Updated	Severity
345269	Linux Distros 未修补的漏洞：CVE-2026-89517	Nessus	Misc.	9/12/2026	11/11/2026	medium
345269	Linux Distros 未修補弱點：CVE-2026-89517	Nessus	Misc.	9/12/2026	11/11/2026	medium
345269	Linux Distros のパッチ未適用の脆弱性: CVE-2026-89517	Nessus	Misc.	9/12/2026	11/11/2026	medium
345269	Linux Distros Unpatched Vulnerability : CVE-2026-89517	Nessus	Misc.	9/12/2026	11/11/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium