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

  - シグナル:exec() の競合を回避します Hyunwoo が次の KASAN UAF splat をデバッグしました: バグ: KASAN:__send_signal_locked+0xb27/0xba0 の slab-use-after-free タスク poc/79 による addr ffff888007ed80c8 でのサイズ 8 の書き込み ... コールトレース:__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 Hyunwoo 氏が説明したように、これは非リーダー exec() で発生することが判明しました。
    de_thread()はrelease_task(leader)の前にexchange_tids()を呼び出すため、リーダーのtidに対して作成されたSIGEV_THREAD_IDタイマーによって保持されるstruct pidは、execve()を呼び出したスレッドを指すようになります。pid_task() はそのスレッドを返し、そのスレッドの lock_task_sighand() は成功します。タイマーシグナルがブロックされると、その sigqueue はリーダーのタスクのキューに残ります::p ending 。その後、release_task() がキューをフラッシュしている間に、そのタイマーの次の有効期限が切れた場合に実行できます。posixtimer_send_sigqueue() は、sigqueue がプレーンな list_empty() ですでにキューに入れられているかどうかをチェックします。list_head::next のみを読み込みます。list_del_init() はアトミックではなく、INIT_LIST_HEAD() は list_head::next を list_head::p rev の前に保存するため、チェックはその間に渡すことができます。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 に従って解放されたタイマーになった後も、これはまだ存在します。この問題は、sighand ロック保持領域外に sigqueue フラッシュを移動する最近のコミットで表面化しました。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)のシグナルキューイングを防止します。- タスクグループが空で、グループが sighand ロックで終了した場合の exit_signals() の PF_EXITING のロック解除の設定を保護します
    - タスクのフラッシュ::p終了信号がすぐそこにあります。保留中のリスト全体を sighand ロック下のオンスタックリストヘッドに移動させることでこれを最適化し、ロックを保持せずにシグナルを解放します。ロックレスフラッシュや、順序が弱いシステムの非リーダーエグゼクティブのケースについて、かなりの議論がなされています。問題は、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.4