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

  - bpf， skmsg：修正使用 ktls rx sk_psock_strp_data_ready（） 爭用 sk_data_ready 的判定，當存在 TLS RX 上下文時，已檢查 tls_sw_has_ctx_rx（） 並推遲到 psock->saved_data_ready，避免與 TLS strparser 對接收佇列的所有權發生衝突 （提交 e91de6afa81c， bpf：使用 ktls 修正正在執行的 sk_skb 程式類型）。sk_psock_verdict_data_ready（） 沒有對等的防護。在配置 RX 之前將通訊端插入 sockmap （BPF_SK_SKB_VERDICT） 時TLS tls_sw_strparser_arm（） 會將sk_psock_verdict_data_ready儲存為 rx_ctx->saved_data_ready。資料到達時：tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready（） = sk_psock_verdict_data_ready（） -> tcp_read_skb（） 透過 __skb_unlink（） 耗盡sk_receive_queue而不呼叫 tcp_eat_skb（），因此不會提前copied_seq。然後，tls_strp_msg_load（） 會找到 tcp_inq（） >= full_len （過時），在現在為空的佇列上呼叫 tcp_recv_skb（），命中 WARN_ON_ONCE（！first），然後返回指向 psock 擁有 （可能已釋放） skb 的 rx_ctx->strp.anchor.frag_list。tls_decrypt_sg（） 隨後會執行該frag_list：釋放後使用。
    套用與 sk_psock_strp_data_ready（） 相同的修正：如果存在 TLS RX 上下文，請呼叫 psock->saved_data_ready （sock_def_readable） 以喚醒 recv（） 等候者並立即返回，讓接收佇列保持不變。TLS保留佇列的唯一所有權，並透過 tls_sw_recvmsg（） 正常解密記錄。（CVE-2026-64025）

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

偵測

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

critical Nessus Plugin ID 327938

版本 1.17