Linux Kernel EUVD-2026-64548

Exploitation requires the receiving socket to have kernel-TLS (kTLS) receive offload active on a TLS 1.3 connection AND to have explicitly enabled the TLS_RX_EXPECT_NO_PAD socket option - this is the exact configuration named in the description and is not the default. The attacker must be the TLS peer and must get the receiver to process a record that is not unpadded application data (e.g., a TLS 1.3 control record) so the code takes the non-zero-copy retry path. Limiting factors: the bug does not fire on default kTLS or user-space TLS stacks, requires the specific opt-in no-pad mode, and the impact is confined to the receiving process's own iovec buffers rather than kernel memory or other processes; the receiver must also be using scatter/multi-segment recvmsg buffers for the misplacement to matter.

The published CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) substantially overstates real-world risk and appears to be a default maximal kernel scoring. Corroborating signals contradict it: EPSS is only 0.21% (11th percentile), the CVE is not in CISA KEV, and no public exploit is identified - only an in-tree selftest reproducer was added. Critically, the CVSS vector implies unauthenticated, default-configuration network exploitation, but the description states the bug is only reachable 'after the receiver enables TLS_RX_EXPECT_NO_PAD,' a non-default, opt-in kTLS setting - verify with vendor, as AC:L/PR:N does not reflect this precondition. The actual impact is corruption/misplacement of decrypted data inside the receiving application's own user-space buffers (tagged Information Disclosure), not kernel-level RCE or privilege escalation, so C:H/I:H/A:H is not supported by the mechanism described. Net assessment: a genuine data-integrity/disclosure bug worth patching on hosts that use kTLS with TLS_RX_EXPECT_NO_PAD, but far lower operational priority than the 9.8 suggests for the general fleet.

A receiving application enables kernel-TLS with TLS_RX_EXPECT_NO_PAD on a TLS 1.3 connection and calls recvmsg() with a multi-segment iovec. A malicious or malfunctioning TLS peer sends a crafted control-type record that triggers the optimistic zero-copy decrypt followed by the kernel-skb retry; the leftover-advanced iterator causes decrypted bytes to be written past the returned length into later iovec segments, corrupting or leaking data the application did not expect to receive. No public exploit is identified, though an in-tree kernel selftest reproduces the misbehavior.