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

  - ipv4：在 RCU 寬限期後釋放inet_opt和ireq_opt tcp_v4_syn_recv_sock（） 將 ireq->ireq_opt 的所有權轉移至子通訊端 （newinet->inet_opt），而不複製它。另一個 CPU 可以同時處理相同要求通訊端的重新傳輸 SYN，並從 tcp_check_req（） 傳送 SYNACK。
    tcp_v4_send_synack（） 和 inet_csk_route_req（） 僅在 rcu_read_lock（） 下讀取 ireq->ireq_opt，然後讀取 ip_build_and_send_pkt（） 和 ip_options_build（） 兩次 opt->optlen。請注意，SYNACK 計時器本身不是問題：它在其請求通訊端上保存一個引用，並且 inet_csk_reqsk_queue_drop（） 在釋放子項之前呼叫 timer_delete_sync（）。自從提交 079096f103fa （tcp/dccp：將 syn_recv 要求安裝到 ehash 表格中） 以來，請求通訊端的處理方式不保留接聽程式鎖定，因此在 SYNACK 仍在建置期間，沒有任何內容可以阻止釋放子通訊端。TCP 子通訊端沒有 SOCK_RCU_FREE，而 inet_sock_destruct（） 使用純 kfree（） 釋放inet_opt，導致 ip_options_build（） 中的釋放後使用。要求通訊端移轉 （net.ipv4.tcp_migrate_req=1 或BPF_SK_REUSEPORT_SELECT_OR_MIGRATE程式） 也存在類似的問題。reqsk_timer_handler（） 使用 inet_reqsk_clone（） 克隆請求通訊端，以便舊的請求通訊端及其克隆共享相同的ireq_opt，然後 reqsk_migrate_reset（） 清除舊請求中的指標。當克隆被釋放時，另一個在舊請求通訊端上保留參照的 CPU 仍然可以使用這些選項（發送 SYNACK，或在 tcp_v4_syn_recv_sock（）） 中建立子項），並且 tcp_v4_reqsk_destructor（） 也使用普通 kfree（）。閱讀器已經使用 RCU，而取代 inet_opt 的其他路徑 （do_ip_setsockopt（）、cipso_v4_sock_setattr（）...） 已經使用 kfree_rcu（）。在 inet_sock_destruct（） 和 tcp_v4_reqsk_destructor（） 中也使用 kfree_rcu（）。IPv6 不受第一個問題的影響，因為 tcp_v6_syn_recv_sock（） 會重複選項。tcp_v6_reqsk_destructor（） 與 ipv6_opt 有相同的移轉問題，這僅由 CALIPSO 設定。此問題將在單獨的修補程式中解決。(CVE-2026-98432)

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

偵測

Linux Distros 未修補弱點：CVE-2026-98432

high Nessus Plugin ID 366212

版本 1.3