CVE-2026-43500
HighCVSS 7.8Exploitation Probability (EPSS)
Very high risk100th percentile - higher than 100% of all known CVEs
Summary
In the Linux kernel, a vulnerability was found in the RxRPC protocol implementation where DATA and RESPONSE packet handlers did not check for shared page fragments (e.g., from splice()). This allowed in-place decryption on shared pages, potentially leading to data integrity issues.
Risk Assessment
The organization is at risk of man-in-the-middle attacks or data leaks, as shared page fragments could be modified by other processes during decryption, potentially enabling RxRPC traffic interception or modification.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit 5a7b5e8c), which extends the check to include skb_has_frag_list() and skb_has_shared_frag() to ensure buffer copy before decryption.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.