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 Distros 未修補弱點：CVE-2026-98256

high Nessus Plugin ID 364267

版本 1.4