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

  - bpf、skmsg：修复判定sk_data_ready与 ktls rx 争用 sk_psock_strp_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（） 没有等效保护。在配置 TLS RX 之前将套接字插入 sockmap （BPF_SK_SKB_VERDICT） 时，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（） 在不调用 tcp_eat_skb（） 的情况下通过 __skb_unlink（） 耗尽sk_receive_queue，因此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 插件 ID 327938

版本 1.17