CVE-2026-64025 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").
sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival:
tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced.
tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free.
Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's BPF (Berkeley Packet Filter) subsystem and specifically affects the interaction between socket operations and TLS (Transport Layer Security) handling through the kernel's TLS stack. The issue stems from a race condition that occurs when a socket is processed with both BPF sockmap verdicts and TLS encryption, particularly when the socket transitions from being managed by BPF to having a TLS RX context configured. The vulnerability manifests in how data ready callbacks are handled during this transition period, creating a scenario where the receive queue can be accessed concurrently by different subsystems without proper synchronization.
The technical flaw lies in the inconsistent handling of data ready callback functions between two similar but distinct kernel components. The sk_psock_strp_data_ready() function correctly implements a guard mechanism that checks for the presence of a TLS RX context using tls_sw_has_ctx_rx() and defers processing to psock->saved_data_ready when such a context exists. This prevents conflicts with the TLS strparser's ownership of the receive queue, ensuring proper handling of encrypted data. However, sk_psock_verdict_data_ready() lacks this equivalent protection, creating an unsafe path when a socket is inserted into a sockmap before TLS RX configuration is complete.
The operational impact of this vulnerability is severe as it leads to a use-after-free condition that can result in system instability and potential privilege escalation. When a TLS RX context becomes active after a socket has been processed through BPF verdicts, the tls_sw_strparser_arm() function saves sk_psock_verdict_data_ready as the rx_ctx->saved_data_ready callback. During subsequent data arrival, the tls_data_ready path executes through tls_strp_data_ready and eventually calls the saved_data_ready function which is sk_psock_verdict_data_ready(). This function drains the socket receive queue via tcp_read_skb() without properly advancing the copied sequence number through tcp_eat_skb(), leaving the queue in an inconsistent state.
The race condition continues as tls_strp_msg_load() discovers that tcp_inq() reports data available when the queue is actually empty, triggering a WARN_ON_ONCE assertion and returning with an invalid frag_list pointer. This pointer references memory that may have been freed by the BPF processing, creating a classic use-after-free vulnerability. The subsequent tls_decrypt_sg() operation walks this invalid fragment list, leading to memory corruption that can be exploited to execute arbitrary code within kernel space.
This vulnerability aligns with CWE-416 (Use After Free) and CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and maps to ATT&CK techniques involving privilege escalation through kernel exploitation. The fix implemented mirrors the approach already established in sk_psock_strp_data_ready() by adding a TLS RX context check before processing data ready events. When a TLS RX context is detected, the function now calls psock->saved_data_ready (which resolves to sock_def_readable) to properly wake waiting receive operations and return immediately without modifying the receive queue. This ensures that TLS retains exclusive ownership of the receive queue for decryption purposes while maintaining proper synchronization between subsystems.
The mitigation strategy requires implementing the same defensive mechanism in sk_psock_verdict_data_ready() that already exists in sk_psock_strp_data_ready(), ensuring consistent behavior across all socket processing paths. This approach maintains the integrity of the TLS stack's receive queue management while preserving the functionality of BPF sockmap verdict operations, preventing the race condition that leads to memory corruption and potential system compromise. The fix represents a targeted solution that addresses the root cause without disrupting existing kernel functionality or introducing new attack surfaces.