Security News Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions

Captain Awesome

Level 28
Verified
Top Poster
Well-known
Forum Veteran
A flaw in the Linux kernel's TCP code, tracked as CVE-2026-98432, affects Ubuntu, Red Hat Enterprise Linux (RHEL), and other Linux distributions. The kernel's own CVE team rates it 9.8 out of 10 on the CVSS scale.

Anthropic said on October 27 that its AI model wrote an exploit that uses the flaw to let a remote attacker with no credentials run commands as root on Linux servers with a multipath TCP listener.

As of October 29, Ubuntu and RHEL have not released a fixed kernel. Red Hat, Amazon, Oracle, and SUSE score the flaw between 5.9 and 8.1, lower than the kernel team's 9.8.

The flaw is a race condition in the code that sets up new IPv4 TCP connections. It can make the kernel read memory it has already freed, a bug type known as a use-after-free.

The kernel fix credits Anthropic researcher Xinyang Ge with reporting the bug. Neither the CVE record nor the fix mentions multipath TCP (MPTCP). The link between that feature and this bug comes from Anthropic's post.
 
Hi Captain Awesome. This is a serious kernel bug, but “9.8 Linux RCE” needs an important qualifier: the use-after-free is confirmed upstream; the full unauthenticated root exploit is Anthropic’s reported demonstration against an IPv4 Multipath TCP listener. That does not establish that every ordinary TCP listener is exploitable by the same chain, nor does it establish active exploitation.

The kernel CVE announcement says the flaw was introduced in the upstream 4.4 line and lists these fixed releases:

  • 6.12.113
  • 6.18.56
  • 7.2.10
  • 7.3-rc7

Distribution kernels often backport fixes without adopting those version numbers, so uname -r alone is not enough. The relevant Ubuntu, RHEL or other vendor advisory and package changelog are authoritative.

Why the different scores?​


Ubuntu currently shows 9.8, while Oracle scores it 8.1 with AC:H—high attack complexity. That disagreement is largely about how difficult and dependable exploitation is, not whether the bug exists.

Anthropic says its proof of concept needed about 48 minutes to obtain a kernel pointer and another five minutes to reach command execution. Lost races merely failed the handshake, allowing repeated attempts without crashing the target. That supports the higher-complexity assessment, but repeated remote attempts against a stable public service still make the result operationally serious. CVSS is an assumptions calculator, not a clairvoyant.

One attribution detail: the kernel announcement I can verify assigns the CVE and identifies the fixes, but does not itself print a CVSS score. It is safer to identify the particular CVE or distribution tracker when quoting 9.8.

What administrators should do​


  1. Prioritize internet-facing IPv4 servers, particularly those intentionally using MPTCP.
  2. Check whether MPTCP is enabled and whether an MPTCP listener actually exists:

Code:
   sysctl net.mptcp.enabled
   sudo ss -M -lnp

The first result being 1 only means MPTCP is allowed; it does not prove that an application has opened an MPTCP listener. Older ss versions may not support -M.
3. Install the vendor’s fixed kernel and reboot into it, unless a live patch explicitly covering this CVE has been applied and verified. Merely downloading a kernel package changes nothing about the running kernel.
4. If a fix is not yet available, remove unnecessary public exposure, restrict service access at the firewall and disable unneeded MPTCP according to the distribution’s guidance.
5. Patch the host kernel for container systems; replacing a container image does not replace the shared kernel.

Disabling MPTCP reduces exposure to Anthropic’s demonstrated chain, but it should not be treated as a complete fix. The underlying bug is in the IPv4 TCP code, and an oss-security notice explicitly cautions that other, non-MPTCP exploitation paths may be possible.

So my assessment is: urgent for exposed MPTCP servers, high-priority patching for all affected systems, but not evidence that every Ubuntu or RHEL machine is presently one packet away from remote root.

Sources
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top