Linux TCP flaw rated 9.8: Upstream fixes are ready, but Ubuntu servers are still waiting

TCP underpins many website requests, API calls and server-to-server connections. Before application data flows, the operating system establishes a connection through the TCP three-way handshake. Because this work happens inside the kernel, the relevant attack surface exists before an application accepts or authenticates a client.

According to the Linux Kernel CVE Team, CVE-2026-98432 concerns IPv4 options associated with a TCP connection request. When the kernel creates a child socket, it transfers ownership of the request's options without copying them. Another CPU handling a retransmitted SYN can still be reading those options concurrently. [1]

If the options are freed while that second CPU is reading them, the kernel can access memory that is no longer valid. This is a use-after-free (UAF): a program continues to use an object after its memory has been released. Outcomes may include memory corruption or a crash, while additional exploit primitives can potentially turn such a fault into code execution.

Updating application libraries or adding an authentication layer does not by itself remove a kernel-side flaw in packet processing. At the same time, network reachability and a confirmed root exploit are not equivalent claims: deployment conditions still matter.

A UAF is not automatically a complete compromise. Reliable remote code execution typically requires further steps to identify useful memory addresses and redirect execution around kernel safeguards.

Anthropic's October 27 research describes an exploit created by an internal, unreleased Claude model against a Linux server exposing an MPTCP listener. MPTCP extends TCP so that a single logical connection can use multiple network paths, for example where several interfaces are available. [3][5]

In the first stage, the exploit induced an information leak that revealed a kernel address and bypassed Kernel Address Space Layout Randomization (KASLR), which makes memory locations harder to predict. In the second stage, the researchers say it used the same underlying flaw to alter a callback pointer and eventually run an attacker-selected shell command as root. [3]

Anthropic reports 48 minutes to obtain the kernel pointer and a further five minutes to execute the command. It also notes that a failed attempt at the race may merely fail the handshake instead of crashing the server, allowing repeated attempts. This is a reported laboratory result, not confirmation of attacks in the wild. [3]

The distinction matters: the vulnerability is in the Linux IPv4 TCP stack, but the publicly described working root-execution chain targets a server with an MPTCP listener. Public evidence does not establish that the same chain works against all conventional TCP listeners.

The Linux Kernel CVE Team published an upstream fix and it has been backported into maintained stable series, including 5.15.223, 6.12.113, 6.18.56 and 7.2.10. The relevant correction uses Read-Copy-Update (RCU) deferred freeing so concurrent readers can finish before the IPv4 options are released. [1]

Ubuntu does not simply ship the newest upstream kernel unchanged. Canonical maintains its own kernel package lines for each release and for cloud or specialized environments. Upstream changes need to be incorporated, tested and distributed through the appropriate Ubuntu packages.

On October 30, the Canonical CVE tracker still showed the standard linux packages for Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 as vulnerable, with fixes in progress. Older releases including 20.04 LTS were also marked vulnerable. The appearance of a planned package version is not evidence that a patch is already available to install. [2]

This is the operational gap: the source tree can be corrected while production machines continue to run vulnerable binaries. Ubuntu may also backport security corrections into kernels carrying older version numbers, so comparing upstream version strings alone cannot confirm patch status.

Even after installing a fixed kernel package, a server can keep running its old kernel until reboot. Both installed packages and the active kernel must be checked.

Start with an inventory of potentially affected hosts and their exposure to untrusted networks. Include on-premises servers, cloud VMs, Kubernetes worker nodes and externally accessible infrastructure. Containers share the host kernel; replacing an application image does not itself patch the host.

Use uname -r to see the running kernel, then identify the Canonical kernel package and check its status against the CVE tracker. Specialized packages such as linux-aws, linux-azure and linux-gcp can have their own release schedules.

Review TCP listeners, inbound firewall rules and security groups. Remove unnecessary public exposure and restrict services that need only internal access. For MPTCP deployments, establish which services actually use MPTCP listeners rather than assuming that kernel support means every TCP connection uses them.

If MPTCP is not needed, limiting it may reduce exposure after operational testing. It is not a complete fix: the underlying bug resides in TCP/IPv4 processing and the published research does not eliminate every other possible exploitation path.

Prepare testing, maintenance windows, rollback and rolling restarts. When the relevant Canonical updates are available, apply them, reboot and verify that the fixed kernel is actually running. A downloaded package is not a completed remediation.

A kernel networking flaw can place many applications at risk even when their own code contains no corresponding vulnerability. Anthropic's results also demonstrate that an AI model can contribute to a sophisticated exploit chain; a single laboratory success does not establish how prevalent such attacks will become.

The verified facts are narrower and more useful: the kernel defect exists, Anthropic reports successful exploitation under specified MPTCP test conditions, and distribution maintainers need time to deliver supported updates. None of these facts justifies saying that every Ubuntu TCP port guarantees remote root access. [1][2][3]

For enterprises, effective vulnerability management must connect advisories to assets, network exposure, service criticality, deployment windows and post-reboot verification. That connection determines what to protect first—even when an upstream fix exists but a usable distribution package has not yet arrived.