Linux Kernel EUVD-2026-32296

Exploitation requires three concurrent conditions: (1) the target system must be actively using the rxrpc protocol, most commonly via an AFS client mount or an rxrpc-based server, so that RESPONSE packets are being received and processed by the kernel; (2) a packet sniffer or kernel subsystem consuming sk_buff clones (e.g., a tcpdump process via AF_PACKET, a netfilter hook, or a BPF program) must be active on the same host at the same time; and (3) local access with at minimum low-privilege credentials is required (CVSS PR:L). Note that operating an AF_PACKET sniffer typically requires CAP_NET_RAW or root, raising the effective privilege requirement for the sk_buff-cloning side above what CVSS PR:L alone implies. Systems that do not use rxrpc - the vast majority of Linux deployments not running AFS - are entirely unexploitable regardless of kernel version. No network-only exploitation path exists; physical or authenticated shell access to the target is a hard prerequisite.

The official CVSS 3.1 score of 5.5 Medium (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) frames this as a local, low-privilege availability issue. The A:H rating is plausible: writing to a shared sk_buff without unsharing it can trigger kernel memory corruption or panic. However, the C:N metric warrants scrutiny - the ENISA tag explicitly marks this as 'Information Disclosure,' and RESPONSE packets carry rxrpc authentication credentials; once decrypted in the shared buffer, that material is visible to any kernel consumer holding a clone. This C:N versus Information Disclosure conflict is not resolved by available data and should be verified with vendor guidance for environments where credential exposure is a concern. EPSS at 0.02% (5th percentile) confirms the vulnerability is not being broadly targeted, and the absence from CISA KEV reinforces low immediate exploitation pressure. Practical risk is further bounded by the requirement for active rxrpc usage (uncommon outside AFS deployments) and a concurrent sk_buff consumer on the same host. This is a real kernel bug worth patching but is not a near-term priority for organizations not running AFS or rxrpc-based services.

A local user on a system with an AFS client mount causes rxrpc RESPONSE packets to be processed during an authentication handshake. Concurrently, a packet capture tool operating via an AF_PACKET socket clones the sk_buff before the rxrpc security handler runs. The handler decrypts authentication credentials in-place within the shared buffer, causing the sniffer to receive the decrypted (and apparently malformed) frame - potentially exposing authentication tokens - or triggering a kernel panic from the unexpected write into the shared region. No public exploit code has been identified at time of analysis.