Linux Kernel TCP Flaw CVE-2026-98432: Which Distributions Have a Patch and What to Do Without One

The Linux kernel TCP flaw CVE-2026-98432 receives a 9.8 out of 10 from the kernel's own CVE team, according to The Hacker News and Cyberkendra [1][2], while Red Hat, Amazon, Oracle and SUSE rate it lower, according to The Hacker News [1]. As of 29 October 2026, moreover, Ubuntu and Red Hat Enterprise Linux (RHEL) had still not published a fixed kernel [1].

If you administer servers, the useful question is not which score is right. What matters is which machines are in play and what you do with them today. The answer runs through one specific kernel feature, multipath TCP (MPTCP), and through a plan that does not depend on the patch arriving.

The flaw is a race condition when TCP connections are set up

According to The Hacker News, the problem lies in the part of the kernel that establishes new TCP connections over IPv4. It is a race condition during the initial TCP handshake [1]. When the handshake completes, the kernel hands the new socket the IP options of the pending request without copying them. If that socket is destroyed while another processor is still using those options to answer a retransmitted request, the kernel ends up reading memory it had already freed [1].

This type of bug is known as a use-after-free: the system keeps using a memory area it had already marked as free. According to the same source, IPv6 is not affected by this race, because in that case the kernel does copy the options [1].

The scope is broad. Cyberkendra, citing the CVE record, states that the flaw has been present since Linux 4.4, so it reaches almost every maintained distribution kernel [2]. The exception, according to Red Hat as reported by that same source, is RHEL 7, whose kernel never received the vulnerable code [2]. Kernel developers applied the fix on 5 October, before the CVE was published, according to The Hacker News [1].

A remote root exploit makes MPTCP the priority criterion

What made this flaw urgent was a publication by Anthropic. According to The Hacker News, on 27 October the company explained that its AI model, Claude, had written an exploit with which a remote, unauthenticated attacker runs commands as root on Linux servers that have a multipath TCP listener [1]. Cyberkendra describes it as a remote exploit that requires no user interaction [2]. Anthropic's publication does not include the exploit code, the kernel version tested or the configuration used [1].

MPTCP lets a single connection use several network paths at once, and in Linux an application has to request it explicitly when opening the socket, according to The Hacker News [1]. That makes it a good first filter: it is not present by default in every service, and finding out which applications use it is a bounded task.

Still, it is worth not going beyond what the sources say. Neither the CVE record nor the kernel fix mentions MPTCP; that link comes only from Anthropic's publication [1]. Red Hat, for its part, states that a remote attacker who reaches an exposed TCP service could trigger the race, and Anthropic does not clarify whether servers without MPTCP can be compromised in the same way [1]. MPTCP marks where to start, not where to stop.

There is also no evidence of real-world attacks. According to The Hacker News, as of 29 October no vendor advisory, nor the CVE record, nor Anthropic's publication reported exploitation, and the flaw did not appear in the copy of CISA's Known Exploited Vulnerabilities catalog that Luxembourg's CIRCL updated on 28 October [1]. Cyberkendra adds that a research group called Innora has published a root-cause analysis and a reproduction environment, although it says it will not release a working exploit in the short term [2].

Between the lowest score and 9.8, the practical decision is the same

The disparity in ratings has a concrete technical explanation. According to The Hacker News, the kernel CVE team added the 9.8 to the record on 24 October, assuming an attacker who sends a connection request with the IPv4 Record Route or Timestamp options and retransmits it to try to win the race; that is why it considers the attack complexity low [1]. Oracle and SUSE agree with the kernel team on almost everything except precisely that complexity, which they rate as high [1].

Red Hat has even shown two readings at once. Its CVE page rates the flaw as moderate, because the race is hard to win and the most likely outcome would be an unexpected kernel crash, while its machine-readable advisory file, updated on 29 October, raised it to important, according to The Hacker News [1]. Cyberkendra notes that it could not independently confirm that change [2].

The reasonable reading is that each organization scores a different scenario, and none of those scenarios is your configuration. A low score that assumes a hard-to-win race carries less weight when an exploit described as working exists. According to The Hacker News, Anthropic also explains that a lost race only makes that connection attempt fail, without bringing the system down, so the attacker can keep trying [1]. Given that, even the lowest rating justifies acting on exposed machines.

As of 29 October, Ubuntu and RHEL still have no fixed kernel

According to Anthropic's publication as cited by The Hacker News, the fix is already in the mainline kernel and in all of its maintained stable branches, but anyone using a distribution only receives it when the vendor publishes its own kernel package [1]. The known status as of 29 October was as follows, according to The Hacker News and Cyberkendra [1][2]:

• Ubuntu: no fixed kernel. All supported versions are listed as vulnerable or with the fix in progress, including cloud, FIPS and real-time kernels.
• RHEL 8, 9 and 10 and OpenShift 4: fix deferred to a future update.
• RHEL 7: not affected.
• Debian: fixed packages for trixie and Debian 12 (bookworm).
• Oracle Linux with the UEK kernel: fixed since 16 October.
• Amazon Linux: some Amazon Linux 2023 kernels fixed; Amazon Linux 2 and the default Amazon Linux 2023 kernel pending.
• SUSE: fixed in SUSE Linux Micro 6.2 and openSUSE Leap 16.0; several SLES versions in testing or in progress.

Neither Red Hat nor Ubuntu gave a publication date [1]. Cyberkendra notes that Ubuntu's tracking system shows fixed versions in preparation [2]. This list is a snapshot with a cut-off date and has probably changed by the time you read it: each vendor's official advisory is what counts. In Ubuntu's case, Canonical publishes its kernel fixes on the ubuntu-security-announce mailing list, including live patches (livepatch) for its LTS kernels [3], so it is worth watching.

Without a patch, the plan rests on inventory, exposure and monitoring

Where a fixed kernel already exists, the sources' guidance is to install it and reboot, because the update only takes effect once the new kernel is running; Cyberkendra reminds readers that uname -r shows the active version so you can compare it with the vendor's advisory [2].

The problem lies with everything else. According to The Hacker News, Red Hat states that no available mitigation meets its criteria of being easy to deploy, suitable for most installations and stable, and no other advisory proposes one [1]. The sources also do not clarify whether disabling MPTCP or blocking connection requests carrying IP options would reduce the risk [1]. That is why it is unwise to improvise configuration changes in production. What you can do is organize the work:

1. Inventory which Linux servers have an MPTCP listener, with their distribution and kernel version.
2. Prioritize those reachable from untrusted networks and, after that, the rest of the exposed TCP services.
3. Check the Canonical and Red Hat advisories so you can apply the official mitigation as soon as it is published.
4. Strengthen monitoring of those machines until a fixed kernel is available.
5. Schedule the reboot into the new kernel as soon as it exists.

Any specific technical measure should be confirmed against the vendor's advisory. In the meantime, monitoring stops being a complement and becomes the main defense; if your team does not have the capacity to do it continuously, managed monitoring and response for exposed servers can cover that temporary gap.

In SMEs and industrial environments, the challenge is knowing where Linux is

When reviewing the inventory, it is worth checking whether there is Linux on application servers, gateways, remote access machines or auxiliary systems between the IT network and the plant network. It is worth identifying where to apply the patch and planning a reboot window that takes production continuity into account.

Here MPTCP is useful again, because it helps bound the scope. You should not assume that an industrial product is affected; the practical step is to check which machines on your network use that feature or expose TCP services to untrusted networks, and to plan ahead the reboot of those that cannot be stopped immediately. Reviewing these dependencies between IT and the plant is part of industrial OT security, and it is best to have it done before the next advisory.

A vulnerability with a publicly described exploit calls for acting on exposure, not on score

The debate between the kernel team's 9.8 and the lower vendor ratings is context. What decides urgency is whether a server has an MPTCP listener or TCP services reachable from untrusted networks, and that can be checked today, without waiting for Ubuntu and RHEL to publish the fixed kernel.

For an industrial or IT SME, the useful work is the same work that serves for the next vulnerability: an up-to-date inventory, minimal exposure, monitoring and planned reboot windows. If you want to organize that starting point, the basic cybersecurity guide for SMEs is a good place to begin.