Cybersecurity News

Cybersecurity News Alert: Linux TCP Flaw Rated 9.8 and 5.9

By Nattapong Sukkasem · Published 2026-11-01 · Updated 2026-11-01.

Most cybersecurity news is about a gap between an attacker and a defender. This one is about a gap between a fix and a fleet. The kernel bug at the centre of it, CVE-2026-98432, is a race condition in the IPv4 TCP handshake, and the code that resolves it was merged upstream on 5 October. The CVE record appeared ten days later.

A race in the IPv4 handshake

The defect lives in the moment a TCP connection becomes real. When a three-way handshake completes, the kernel promotes a pending request into a full socket and hands over the IPv4 options attached to the original request, Record Route and Timestamp. It hands them over by reference rather than by copy.

If that new socket is torn down while another CPU is still reading those options to answer a retransmitted connection request, the kernel reads memory it has already freed. The upstream fix makes the kernel wait for other readers to finish before releasing the options. The IPv6 path was never affected, for the unglamorous reason that it copies the options instead of sharing them.

The outcome is the familiar use-after-free ladder: read freed kernel memory, then corrupt it. What makes it worth attention on exposed server infrastructure is the precondition, which is almost nothing. The attacker needs no credentials, no prior access and no user interaction. They need to be able to open a TCP connection and lose the race repeatedly, because a lost race does not crash the machine.

Five scorers and five numbers

Severity is supposed to be the part that is settled. Here it is the part that is not.

The spread is not a rounding difference. It is a disagreement about whether winning the race is easy, and it carries straight into operations, because most patching policies are written against a number rather than against a mechanism. A 9.8 triggers an emergency change window. A 5.9 goes into the next monthly cycle. The same kernel, the same packet, two different answers to the question of whether anyone should be woken up. As of 28 October the national vulnerability database carried the kernel team's 9.8 without having published an assessment of its own.

The distributions that shipped, and the two that did not

The kernel maintainers repeat their standing advice: move to the latest stable release rather than cherry-picking a single fix. That advice is unhelpful to anyone running a vendor kernel, which is the point. This piece of cybersecurity news is the inverse of a zero-day vulnerability. Nothing was unknown and nothing was unfixed; the entire exposure lived in the distance between an upstream commit and a signed vendor package.

It is also where cloud security stops being an abstraction and becomes a scheduling fact. An identical workload was patchable on Amazon Linux 2023 from 24 October and, on RHEL 9, not patchable at all. The distribution a platform hands you decides your patch date more than your own change process does.

The exploit nobody outside a lab has seen

The reason this flaw escaped the usual kernel-CVE churn is that someone published an account of exploiting it. Anthropic credited its researcher Xinyang Ge in the upstream fix and, in a post dated 27 October, said an unreleased internal model wrote a working exploit after initial prompting: roughly 48 minutes to leak a kernel address and defeat address-space randomisation, then five more to overwrite a callback pointer and run a command as root.

There is no rule to write

The reflex for a remote kernel flaw is to narrow the path to it. That reflex has nowhere to go here. The vulnerable code runs during connection setup on any listening IPv4 port, so the mitigation that would work — do not accept TCP from strangers — is a description of switching the service off. A perimeter rule dropping inbound packets that carry IPv4 Record Route or Timestamp options is the one plausible control, and no vendor advisory confirms it is sufficient. Red Hat has said plainly that no mitigation it has found meets its own bar for being easy to deploy and stable, and the Go security team calls its own GODEBUG=multipathtcp=0 switch fragile.

Detection is no kinder. A DDoS attack announces itself in a graph: the volume is the attack, and every dashboard you own moves. This arrives as connection attempts you already accept, repeated patiently for most of an hour, at a rate that looks like a client on a poor link. Nothing crashes on a failed attempt, so there is no error rate to alert on either.

Where resolution comes into it

Name servers are an unusually exposed population for a bug like this. A recursive resolver or an authoritative name server exists to accept connections from parties it has no relationship with, and it accepts them over TCP more often than people assume: TCP fallback for responses too large for a datagram, zone transfers, and increasingly a persistent encrypted session. DNS over HTTPS and DNS over TLS are usually discussed as privacy features for clients, but on the server side they turn a resolver into a long-lived inbound TCP endpoint on 443 or 853. That is the exact population this defect cares about.

Two things follow that are worth measuring rather than assuming. First, the attack never becomes a DNS query, so the one log most operators keep for a resolver will be silent by construction; the evidence, if any exists, is in kernel and connection telemetry, not in query logs. Second, the IPv6 path is not affected, which means a dual-stack resolver has one half an attacker cannot use. Knowing what share of your resolution actually arrives over IPv4 turns that from trivia into a number you can act on.

What to check this week

1. Patch to a stable kernel, not to a score. Compare your running kernel against 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The version number is the fact; the severity rating is an opinion, and five of them are in circulation.
2. Decide which number your process obeys. If your policy keys off a vendor CVE page, this flaw is a 5.9 and will wait for the monthly window. Make that a decision somebody took rather than a default.
3. Treat the no-fix distributions as a standing item. Ubuntu LTS and RHEL 8, 9 and 10 need a recheck on a schedule, not a one-off look, and the older Ubuntu releases are not getting a fix at all.
4. Find the hosts that accept IPv4 TCP from anywhere. Name servers, mail gateways, load balancers and reverse proxies are the first tier for any handshake-path flaw, and they are also the hosts with the worst reboot windows.
5. Consider dropping exotic IP options at the edge. Record Route and Timestamp have no role in ordinary traffic. Filtering them is cheap IT security hygiene whether or not it blocks this particular path.
6. Baseline before you patch. A network diagnostic tool run against your own resolvers records what healthy looks like, which is what lets you tell a bad kernel update from a bad day.

What it means

The honest summary is a short list of things that are not known. No vendor advisory, the CVE record or Anthropic's own post reports exploitation in the wild. The identifier was not in the Known Exploited Vulnerabilities catalogue as of 28 October. The link between the published exploit account and the public CVE record exists only in that account. And the multipath TCP precondition, which is the difference between a serious bug and an emergency, is asserted in one place and absent from the two authoritative ones.

What is known is the shape of the failure, and it is not a technical one. A fix existed on 5 October. Three distributions shipped it within eleven days. Two did not ship it within twenty-four, while publishing severity ratings that differed by nearly four points on a ten-point scale. For anyone who runs Linux at scale, the lesson of this cybersecurity news cycle is that the number arriving with a vulnerability is a vendor's judgement, not a measurement — and that the useful question is never how severe a flaw is, but how far your own fleet sits from the commit that fixed it.

Sources

• The Hacker News — Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions
• The Hacker News — Anthropic's Unreleased AI Model Chains Flaws Into Working Chrome, Safari, Windows and Linux Exploits
• Aviatrix Threat Research Center — CVE-2026-98432: Linux Kernel TCP 9.8 CVSS Flaw Hits Ubuntu and RHEL

Related articles

• Cybersecurity News Alert: 333 Tor Exit Relays Hijacked October 23, 2026 · Cybersecurity news
• Ads Became a Spyware Delivery Network October 18, 2026 · Cybersecurity news
• Tech Infrastructure Alert: Two Flaws Break Wasm Sandboxes October 27, 2026 · Tech infrastructure

Browse every DNS news article by month →

DNS angle

Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.

Source: The Hacker News — Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions (2026-10-29).