CVE-2026-43384

What it actually does

The flaw is a cryptographic timing side channel in the Linux kernel TCP Authentication Option implementation. TCP-AO message authentication codes were compared using a comparison operation that could return earlier when bytes differed, rather than using a constant-time comparison. A remote attacker who can send crafted TCP-AO-protected packets and accurately measure response or processing timing may be able to infer valid MAC values over repeated attempts. If successfully exploited, this can undermine TCP-AO authentication and allow forged authenticated TCP traffic, potentially enabling injection, disruption, or manipulation of protected TCP sessions such as routing protocol peerings that rely on TCP-AO.

Why it matters to the business

Organizations using Linux systems for TCP-AO-protected network services, especially routing or infrastructure control-plane communications, could face disruption or manipulation of trusted TCP sessions if the side channel is practically exploited. Business consequences may include routing instability, loss of service availability, traffic misdirection, degraded network trust boundaries, and operational outages. Although the CVSS score is critical, public exploit maturity is currently reported as none, EPSS is low, and the issue is not known to be in CISA KEV, so urgency should be highest for systems that actually enable TCP-AO on exposed or infrastructure-critical links.

How an attack unfolds

An attacker first identifies Linux hosts participating in TCP-AO-protected TCP sessions or services that accept TCP-AO traffic. The attacker then sends many crafted TCP segments containing TCP-AO authentication data with guessed MAC values. Because the vulnerable kernel comparison may take measurably different time depending on how much of the supplied MAC matches the expected MAC, the attacker attempts to use timing measurements as an oracle to recover valid authentication data incrementally. If enough signal can be extracted despite network jitter and rate limits, the attacker may be able to forge packets that pass TCP-AO validation. Successful forgery could permit spoofed TCP resets, injected data, disruption of established protected sessions, or manipulation of control-plane communications. Practical exploitation depends heavily on network position, timing precision, TCP-AO deployment, key configuration, and the ability to send a large volume of probes without detection.

How to fix it

Apply Linux kernel updates from the relevant distribution or vendor that include the TCP-AO constant-time MAC comparison fix. Because no universal fixed version was provided, use vendor advisories for the exact kernel package version for each distribution and platform. Where immediate patching is not possible, reduce exposure by disabling TCP-AO where it is not required, restricting TCP-AO-protected services to trusted peer addresses, applying strict ingress filtering and anti-spoofing controls, limiting management/control-plane access to trusted networks, and monitoring for abnormal TCP-AO authentication failures or probe-like traffic. Rotate TCP-AO keys if there is evidence that the protected session was actively targeted, but key rotation alone does not remove the timing flaw.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the upstream or vendor fix for constant-time TCP-AO MAC comparison. Check the active kernel version after reboot, not only the installed package version. Review distribution security advisories or changelogs for references to the TCP-AO constant-time MAC comparison fix. Validate exposure by determining whether TCP-AO is enabled or configured on the host and whether TCP-AO-protected ports are reachable from untrusted networks. Network validation can include packet capture review for TCP option kind 29, which indicates TCP-AO traffic. After patching, continue monitoring for repeated invalid TCP-AO packets or authentication failures to confirm that attempted probing is not ongoing.

Typical attack path

1. Discover or infer a Linux endpoint using TCP-AO for protected TCP communications.
2. Obtain a network position that allows sending TCP segments to the protected endpoint and measuring timing behavior with sufficient precision.
3. Generate repeated TCP-AO packets with varying MAC guesses.
4. Measure response timing or observable processing differences to infer partial correctness of MAC guesses.
5. Iterate the timing attack until a valid MAC can be forged or session authentication is weakened enough for follow-on actions.
6. Send forged authenticated TCP traffic, such as injected data or reset packets, to disrupt or manipulate the protected session.

How to detect it

There is no single reliable artifact that proves exploitation because the attack is a timing side channel against TCP-AO verification. Investigations should focus on whether TCP-AO is in use and whether there were abnormal patterns consistent with timing-oracle probing. Review packet captures, NetFlow/IPFIX, firewall logs, router logs, kernel logs, and routing protocol logs for high volumes of TCP segments carrying TCP-AO from unexpected sources, repeated failed authentication or malformed TCP-AO traffic, unexplained session resets, routing adjacency flaps, or bursts of near-identical TCP-AO packets with varying authentication data. For infrastructure protocols, correlate suspected probing with BGP or other TCP-based control-plane session instability. If packet captures are available, inspect TCP option kind 29 traffic, especially repeated packets from non-peer addresses or unusually high retry rates. Because timing attacks may leave only network-level traces, absence of logs does not rule out probing.

What your security team should do

• Inventory Linux systems that use TCP-AO, prioritizing routers, route servers, network appliances, and infrastructure hosts participating in authenticated TCP control-plane sessions.
• Patch affected Linux kernels using vendor-provided fixed packages and reboot into the corrected kernel.
• Prioritize remediation for internet-exposed or untrusted-network-reachable TCP-AO endpoints despite the currently low EPSS and no known KEV listing.
• Restrict TCP-AO peers with host firewalls, router ACLs, control-plane policing, and source-address validation.
• Capture baseline TCP-AO traffic patterns and alert on spikes in TCP-AO packets, repeated authentication failures, malformed TCP-AO options, or unexpected peers.
• Review routing and control-plane logs for unexplained session resets, adjacency flaps, or anomalous authenticated TCP session behavior around the exposure window.
• If exploitation is suspected, rotate TCP-AO keys after patching and investigate peer integrity before restoring normal trust.