NoisyTCP: Linux Kernel TCP Pre-Auth Remote Corruption (CVE-2026-99288)

The vulnerability, named NoisyTCP, was discovered by security researcher Hyunwoo Kim and has existed in the Linux kernel since 2015. It affects almost all Linux distributions and can be triggered remotely against servers that receive TCP packets directly, including those running Nginx, Apache, and SSH with default configurations.

The vulnerability requires specific conditions to be exploited, including a stale ehash lookup and concurrent freeing and reallocation of a request socket in different receive contexts. This makes it particularly effective against servers with multiple receive queues or where RPS (Receive Packet Steering) distributes packets across multiple CPUs.

Attack Methods

There are two primary methods to trigger this vulnerability. The first involves a request_sock Reuse ABA Race, where a stale lookup finds an existing request socket that has been freed and reallocated. This can lead to a kernel panic when the TCP receive path dereferences a NULL listener, causing a remote denial-of-service (DoS) attack.

The second method, a Full child socket ABA Race, can potentially lead to remote use-after-free exploitation, though it requires more complex race scenarios to succeed. While the vulnerability has been confirmed to cause DoS attacks, a general-purpose remote code execution (RCE) exploit has not yet been developed.

Impact and Timing

The impact of this vulnerability varies depending on the server environment. Against virtual machines like QEMU/KVM with default configurations, the attack can be triggered in about 5 seconds to 2 minutes. However, against a quiet bare-metal server with 8 RX queues, it took approximately 14 hours to trigger even with a carefully proof-of-concept exploit.

Notably, if a DoS attack is successfully executed against a web server running in a container, it takes down not only the web server application but the entire host system, potentially affecting multiple services simultaneously.

Available Solutions

The primary solution is applying the patch (4e2b3ef19e0e) that fixes the vulnerability, which was introduced on November 3, 2026. For systems unable to apply the patch immediately, two temporary mitigations are available.

First, administrators can disable SYN cookies using the command 'sudo sysctl -w net.ipv4.tcp_syncookies=0'. This must be applied to each container using a separate network namespace and reduces protection against SYN floods. Second, reducing the RX queues to one and disabling RPS and RFS can block the race condition required for exploitation.

The vulnerability underscores the importance of timely patching for critical infrastructure components, especially those exposed to the internet with default configurations.