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

  - signal：防止 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 事實證明，這種情況發生在非領導者 exec（） 上，正如 Hyunwoo 所解釋的那樣：
    de_thread（） 在 release_task（leader） 之前呼叫 exchange_tids（），因此針對 leader 的 tid 建立的 SIGEV_THREAD_ID 計時器所持有的結構 pid 現在指向呼叫 execve（） 的執行緒。pid_task（） 傳回該執行緒，其上的 lock_task_sighand（） 成功。如果計時器訊號被封鎖，其 sigqueue 會在領導者的 task：:p ending 上保持佇列。然後，該計時器的下一個到期可以在 release_task（） 排清佇列時執行。posixtimer_send_sigqueue（） 檢查 sigqueue 是否已使用純 list_empty（） 排入佇列，該 （） 僅讀取 list_head：：next。list_del_init（） 不是不可部分完成的，並且 INIT_LIST_HEAD（） 在 list_head：:p rev 之前儲存 list_head：：next，因此檢查可以在兩者之間傳遞。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 進入釋放的計時器。這個問題在最近的提交中浮出水面，該提交將 sigqueue 排清移出 sighand 鎖定保留區域。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） 的訊號排入佇列。- 保護 exit_signals（） 中工作群組空白的解鎖 PF_EXITING 設定，以及具有 sighand 鎖定的群組結束案例
    - 沖洗任務：:p結束信號就在那裡。透過將整個擱置清單移動到嘆息鎖定下的堆疊上清單頭來優化這一點，並在不保留鎖定的情況下釋放訊號。關於弱排序系統上的無鎖刷新和非領導者執行案例已經有相當多的討論。問題在於，嘗試傳送 posix 計時器訊號的第三方依賴 PID 查詢來尋找目標任務，而當訊號最初導向至舊的領導者時，該查詢可能會導致新的領導者。如果訊號在舊的領導線上排隊，則無鎖定刷新會引起對以下情況的擔憂： old_leader new_leader 第三方 A：flush_list（） // list_del_in ---truncated--- （CVE-2026-98256）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  - signal：防止 exec（） 争用 Hyunwoo 调试了以下 KASAN UAF splat：缺陷：KASAN：0xb27__send_signal_locked任务 poc/79 在地址 ffff888007ed80c8 处的 slab-use-after-free：0xba0 ... 调用跟踪：__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 事实证明，这种情况发生在非领导者 exec（） 上，正如 Hyunwoo 所解释的那样：
    de_thread（） 在 release_task（leader） 之前调用 exchange_tids（），因此针对 leader 的 tid 创建的 SIGEV_THREAD_ID 定时器保留的结构 pid 现在指向调用 execve（） 的线程。pid_task（） 返回该线程，lock_task_sighand（） 会成功。如果定时器信号被阻断，其 sigqueue 将在领导者的 task：:p ending 上保持排队状态。然后，该定时器的下一个到期时间可在 release_task（） 刷新队列时运行。posixtimer_send_sigqueue（） 检查 sigqueue 是否已使用仅读取 list_head：：next 的普通 list_empty（） 进行排队。list_del_init（） 不是原子型的，INIT_LIST_HEAD（） 在 list_head：:p rev 之前存储 list_head：：next，因此检查可以在两者之间传递。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 进入释放的定时器。在最近的提交中出现了此问题，该提交将 sigqueue 刷新移出了 sighand 锁定保留的区域。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） 的信号排队。- 保护 exit_signals（） 中针对任务组为空的任务组和具有 sighand 锁定的组退出情况的未锁定的PF_EXITING设置
    - 刷新任务：:p结束信号就在那里。通过将整个待定列表移动到 sighand 锁定下的堆栈上列表头来优化这一点，并在未保留锁定的情况下释放信号。关于弱顺序系统上的无锁刷新和非前导 exec 情况，已经有相当多的讨论。问题在于，尝试发送 posix 定时器信号的第三方依赖 PID 查找来查找目标任务，并且当信号最初定向到旧前导时，该查找可能会生成新的前导者。如果信号在旧前导线上排队，则无锁刷新会引起对以下情况的关注：old_leader new_leader 第三方 A：flush_list（） // list_del_in ---truncated--- （CVE-2026-98256）

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

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 は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

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

  - signal: Prevent exec() race Hyunwoo debugged the following KASAN UAF splat: BUG: KASAN: slab-use-after-     free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call     Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0
    __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030
    __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0     kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation:
    kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90     begin_new_exec+0xa6b/0x28c0 It turned out that this happens with a non-leader exec() as Hyunwoo explained:
    de_thread() calls exchange_tids() before release_task(leader), so the struct pid held by a SIGEV_THREAD_ID     timer created against the leader's tid now points to the thread which called execve(). pid_task() returns     that thread and lock_task_sighand() on it succeeds. If the timer signal is blocked, its sigqueue stays     queued on the leader's task::pending. The next expiry of that timer can then run while release_task()     flushes the queue. posixtimer_send_sigqueue() checks whether the sigqueue is already queued with a plain     list_empty(), which only reads list_head::next. list_del_init() is not atomic and INIT_LIST_HEAD() stores     list_head::next before list_head::prev, so the check can pass in between. list_add_tail() queues the entry     on the task::pending of the live thread, and the list_head::prev store from the flush then overwrites the     list_head::prev link that list_add_tail() has just set. __flush_itimer_signals() does not undo that     either. With list_head::prev pointing at the entry itself, its list_del_init() only stores the same values     again, so the entry is not removed from the list. It is still there after the last reference is dropped     and the timer is freed by RCU, and the list_add_tail() of a later tgkill() follows that list_head::prev     into the freed timer. This problem surfaced with the recent commit which moved the sigqueue flush out of     the sighand lock held region. Hyonwoo proposed to fix this by using list_del_init_careful(), but that just     papers over the problem. After some disucssions and various attempts to solve it, Eric pointed out that     there is no reason to flush task::pending late in release_task() and it should be done in exit_signals()     already. As nothing can collect and deliver signals which are queued in a dying task's pending queue,     there is no reason to delay it further. But it has to be ensured that no signals can be queued into it     after that point. exit_signals() sets PF_EXITING in task::flags, which can be used as an indicator for     this. Cure it by: - Preventing signal queueing for task private signals (PIDTYPE_PID) when the task has     PF_EXITING set in __send_signal_locked() and in posixtimer_send_sigqueue(). - Protecting the unlocked     setting of PF_EXITING in exit_signals() for the task group empty and the group exit case with sighand lock
    - Flushing task::pending signals right there. Optimize that by moving the whole pending list to an on-     stack list head under sighand lock and free the signals without the lock held. There has been quite some     discussion about the lockless flush and the non-leader exec case on weakly ordered systems. The problem is     that a third party which tries to send a posix timer signal relies on the PID lookup to find the target     task and that lookup might result in the new leader when the signal was originaly directed to the old     leader. In case that the signal was queued on the old leader then the lockless flush raised a concern over     the following situation: old_leader new_leader third party A: flush_list() // list_del_in ---truncated---     (CVE-2026-98256)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
364267	Linux Distros 未修補弱點：CVE-2026-98256	Nessus	Misc.	2026/10/8	2026/10/10	high
364267	Linux Distros 未修补的漏洞：CVE-2026-98256	Nessus	Misc.	2026/10/8	2026/10/10	high
364267	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98256	Nessus	Misc.	2026/10/8	2026/10/10	high
364267	Linux Distros Unpatched Vulnerability : CVE-2026-98256	Nessus	Misc.	2026/10/8	2026/10/10	high

検出

プラグインの検索

high

high

high

high