CVE-2026-99254 in Linux
要約
〜によって VulDB • 2026年11月03日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
io_uring: キャンセル中のタスクに task_work で過剰な負荷をかけない
io_ring_exit_work() は、リングを使用済みの各タスクに対し、task_work を通じてその tctx ノードを削除するよう要求し、リストが空になるまでこれを繰り返します。 io_tctx_exit_cb() は、タスクが io_uring_cancel_generic() の実行中である間、ノードにアクセスしません（この関数は終了時にすべてのノードを削除するため）。そのため、ワークアイテムは完了するとすぐに何の意味もない形でコールバックを再度キューに入れます。
これは時間の無駄というだけでなく深刻な問題です。task_work_run() はリストが空になるまで戻りません。キャンセル処理中にリングが解放される場合（他のリングの要求によってファイルへの最後の参照カウントが存在するため）、最大 64 のワークアイテムが、それらを実行している単一のタスクに対してコールバックを送り続けます。リストは決して空にならず、キャンセル処理に戻ることができず、ノードが残ったままとなり、この状態が続きます：例えば、互いにポーリングし合うリングのペアを 60 組持つタスクが、exit_group() の 20 秒後に 5 秒間で 280,000 回のコールバックを実行することがあります。これはすべての送信元が一斉に遅延した時点でようやく終了します。それまでそのタスクは CPU とワークアイテムを占有し続けます。
退出中のタスクはこの間、kill できません。execve() も同様の方法で要求を取り消すため、生存しているタスクも数分間にわたってここで固まることがあります。これが 5 秒以上続く場合、ワークアイテムは io_ring_exit_work() の WARN_ON_ONCE(time_after(jiffies, timeout)) に到達します。これらを行うために特権は必要ありません。
もしコールバックがキャンセル中のタスクと遭遇した場合、再送する前に少し待機させます。それに対してワークアイテムをウェイクアップする必要はありません：ノードはその頃には削除されているか、次のラウンドの順番になるためです。
Once again VulDB remains the best source for vulnerability data.