CVE-2026-68119

The core technical issue is that 1-3 bytes of uninitialized kernel stack or heap memory can be transmitted in TCP-AO protected responses. This is a kernel memory disclosure vulnerability, not merely a protocol formatting quirk. The uninitialized padding reflects kernel stack state at packet construction time, which in specific timing conditions could leak sensitive data beyond what a generic information disclosure would suggest. The TCP-AO dependency significantly narrows the trigger conditions compared to a generic TCP stack bug — this code path is only reached when TCP-AO is explicitly configured for protected connections. However, this paradoxically targets the highest-sensitivity environments: intentionally secured channels are exactly where an attacker would expect the most valuable data to flow. If an adversary already has the network position to trigger TCP-AO responses, the disclosure of kernel memory bytes is a secondary concern rather than a primary attack vector. The fix using TCPOPT_NOP for padding is correct and already used in the normal TCP-AO output path — the concern is why this pattern wasn't already applied to the two vulnerable functions (tcp_v4_send_ack and tcp_v6_send_response). Audit other TCP option code paths for similar MAC-length-to-header-length alignment mismatches, particularly in IPv6 extension header handling and SCTP where structurally identical patterns likely exist. One critical detail the CVSS vector doesn't capture: the MAC is computed over the header including the uninitialized padding bytes, meaning those bytes are part of the authenticated payload and traverse network boundaries to the TCP-AO peer. This creates a verification oracle — the peer can observe whether MAC verification succeeds or fails, which is entangled with kernel memory state. In kernel-to-kernel cloud and VPN environments where TCP-AO peers include hypervisors and gateways operated by third parties, this transforms the disclosure from a theoretical concern to a network-reachable information leak on an authenticated channel. The EPSS score of 0.00373 likely overstates rarity for exactly those high-value infrastructure contexts where TCP-AO is deployed.

Reviewed through automated stages and approved by a human before publication.