Cloudanix VulnDB

CVE-2026-68119

High · 7.5

CVSS

7.5

EPSS

0.4%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux networking bug could cause a few bytes of internal memory to be accidentally sent out in certain special network reply packets.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

In TCP-AO response paths, tcp_v4_send_ack and tcp_v6_send_response leave one to three bytes of padding after the MAC uninitialized before transmission; tcp_ao_hash_hdr also fails to initialize those bytes before MAC computation, allowing residual kernel memory to be sent on the wire.

Why it matters to the business

Unintended leakage of small amounts of kernel memory contents over the network in TCP-AO traffic, increasing risk of sensitive data exposure in environments using authenticated TCP options.

How an attack unfolds

An attacker establishes or triggers TCP-AO authenticated sessions, forces the kernel to emit standalone ACK or response segments, and inspects the option padding bytes in the captured packets for any residual uninitialized data that may contain kernel memory fragments.

How to fix it

Upgrade the Linux kernel to a version containing the commit that initializes TCP-AO padding with TCPOPT_NOP before hashing and transmission; rebuild and reboot affected systems.

How to confirm the fix worked

Verify the presence of the padding-initialization change in tcp_ao.c or tcp_ipv4.c / tcp_ipv6.c source, or confirm the running kernel version reports the fix; perform packet captures of AO responses to ensure padding bytes are now zeroed or NOPs.

Typical attack path

  1. Identify hosts advertising TCP-AO support or responding to AO-enabled probes
  2. Craft and send packets that elicit tcp_v4_send_ack or tcp_v6_send_response with AO options
  3. Capture the resulting segments and extract bytes beyond the declared MAC length
  4. Analyze leaked bytes for kernel pointers, stack data, or other sensitive values

How to detect it

Inspect packet captures for TCP segments carrying the TCP-AO option where the option length field indicates a non-multiple-of-4 MAC and the following 1-3 bytes contain non-NOP, non-zero values; correlate with tcpdump or tcpflow logs showing AO responses from kernel versions prior to the fix.

  • TCP option kind 29 with length not aligned to 4 bytes followed by non-zero padding
  • Outbound TCP segments with AO MAC followed by values other than 0x01 (NOP)

What your security team should do

  • Prioritize kernel updates for any system using TCP-AO
  • Review network configurations to limit exposure of TCP-AO enabled services
  • Add kernel version checks to vulnerability scanning policies

The record

In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.

Affected packages

Ecosystem Package Introduced Fixed