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

  - sctp：在過時 cookie 錯誤時捨棄封包的其餘部分 當關聯處於 COOKIE-ECHOED 狀態，且對等體從其中一個非主要位址傳送捆綁的 [ERROR（Stale Cookie）][DATA] 封包時，處理 ERROR 區塊會採用非致命過時 cookie 重試路徑 sctp_sf_do_5_2_6_stale（），該路徑會SCTP_CMD_DEL_NON_PRIMARY佇列，同時保持關聯處於活動狀態。sctp_cmd_del_non_primary（） 會移除所有非主要傳輸 - 包括此封包到達的傳輸，該傳輸仍由接收查詢引用，並由封包的所有區塊透過區塊>傳輸共用。
    sctp_assoc_rm_peer（） 確實會將 asoc->peer.last_data_from 從已移除的傳輸中重新導向，但緊接著，捆綁的 DATA 區塊會使 sctp_assoc_bh_rcv（） 無條件地重新註冊 asoc->peer.last_data_from = chunk->transport，使用剛剛移除的傳輸撤消重新導向。封包完成後，接收參照會捨棄，傳輸會釋放 RCU，而倖存的關聯會保留懸空last_data_from。稍後的 FWD-TSN（或延遲的 SACK 計時器）使 sctp_gen_sack（） 取消參照它 （->param_flags 和朋友），並且 sctp_make_sack（）/sctp_outq_select_transport（） 可能會寫入釋放的物件並將其連結到即時傳輸清單中。這是可由任何惡意 SCTP 對等體 （或充當其中的本機無特權使用者） 觸發的釋放後使用，不需要任何功能： 錯誤：
    KASAN：在 sctp_do_sm+0x498a/0x5660 中的 slab-use-after-free 由任務 poc/115 在 addr ffff88800e1e356c 讀取大小 4 呼叫追蹤：sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv 已分配：sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init （INIT-ACK 處理） 已釋放： kfree <- sctp_transport_destroy_rcu <- rcu_core （call_rcu 在 sctp_rcv 結束時被 sctp_transport_put 排入佇列） 有錯誤的位址位於釋放的 1024 位元組區域內 364 位元組 [ffff88800e1e3400， ffff88800e1e3800），快取 kmalloc-1k 請注意，提交 03a9d10ecf71 （sctp：如果區塊的傳輸被移除，則丟棄區塊） 僅涵蓋接收查詢和區塊處理之間的視窗 （例如，ASCONF DEL-IP 爭用通訊端待辦專案）;這裡移除了運輸
    *當* 封包由同一封包的較早區塊處理時，因此 sctp_inq_push（） 中的丟棄不會到達此路徑。已使用捆綁的 [ERROR（Stale Cookie）][DATA] + FWD-TSN reproducer 驗證：上述 KASAN 報告在套用該提交的情況下仍會觸發，並且此修補程式位於頂部。按照 Xin 的建議，透過捨棄此路徑上的其餘封包來修復它。在 stale-cookie ERROR 將關聯傳回 COOKIE-WAIT 並移除非主要傳輸之後，封包的其餘區塊只能針對重新啟動的交握執行，同時透過 chunk->transport 參照已移除的到達傳輸：除了上述last_data_from註冊之外，sctp_cmd_setup_t2（） 和 sctp_make_*（） 回覆產生器也會將該指標複製到 sctp_assoc_rm_peer（） 已經清理的關聯存留期狀態。讓對等體重新傳輸它們，與 sctp_inq_push（） 對在處理前刪除傳輸的區塊所做的操作一致。（CVE-2026-98548）

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

偵測

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

critical Nessus Plugin ID 367479

版本 1.8