CVE-2026-64025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, skmsg: fix verdict sk_data_ready racing with ktls rx<br /> <br /> sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and<br /> defers to psock-&gt;saved_data_ready when a TLS RX context is present,<br /> avoiding a conflict with the TLS strparser&amp;#39;s ownership of the receive<br /> queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types<br /> with ktls").<br /> <br /> sk_psock_verdict_data_ready() has no equivalent guard. When a socket<br /> is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is<br /> configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready<br /> as rx_ctx-&gt;saved_data_ready. On data arrival:<br /> <br /> tls_data_ready -&gt; tls_strp_data_ready -&gt; tls_rx_msg_ready<br /> -&gt; saved_data_ready() = sk_psock_verdict_data_ready()<br /> -&gt; tcp_read_skb() drains sk_receive_queue via __skb_unlink()<br /> without calling tcp_eat_skb(), so copied_seq is not advanced.<br /> <br /> tls_strp_msg_load() then finds tcp_inq() &gt;= full_len (stale), calls<br /> tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and<br /> returns with rx_ctx-&gt;strp.anchor.frag_list pointing at a psock-owned<br /> (potentially freed) skb. tls_decrypt_sg() subsequently walks that<br /> frag_list: use-after-free.<br /> <br /> Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context<br /> is present, call psock-&gt;saved_data_ready (sock_def_readable) to wake<br /> recv() waiters and return immediately, leaving the receive queue<br /> untouched. TLS retains sole ownership of the queue and decrypts the<br /> record normally through tls_sw_recvmsg().