The Linux TCP Bug an AI Model Weaponized: A 9.8 Flaw Still Unpatched on Ubuntu and RHEL

On October 27, 2026, Anthropic's Frontier Red Team published a report with a headline that made every sysadmin's stomach drop: an unreleased Claude research model chained together working exploits across five platforms — Chrome, Safari, a locked Android phone, Windows, and Linux — with minimal human hand-holding. The Linux one is what I want to talk about, because it's a zero-click, unauthenticated, root-level bug sitting in the kernel's IPv4 TCP code, and as of this week two major distros still don't have a fix.

The bug is CVE-2026-98432, a use-after-free in the Linux kernel's TCP stack, and the kernel's own CVE team rates it 9.8 out of 10.

Here's the short version: Debian, Amazon Linux, Oracle Linux, and SUSE have shipped patched kernels. Ubuntu and Red Hat have not. If you're running Ubuntu 22.04 through 26.10, any current RHEL release, or an AlmaLinux box that tracks RHEL upstream (like my own VPS), you're currently waiting on your vendor — and Red Hat has been explicit that it has no release date yet.

Until your distro ships a fix, there's an nftables rule that drops incoming IPv4 TCP packets carrying IP options (full rule below). It cuts down your exposure. It does not patch the hole.

Start here:

# What kernel am I running?
uname -r

# Any MPTCP listeners on this host? (the exploit targets these)
ss -M -l

# Does my distro's advisory page know about this CVE yet?
cat /etc/os-release | grep VERSION_ID
# then check your vendor's CVE tracker for CVE-2026-98432

If ss -M -l turns up listeners and your kernel version predates the fixed releases below, keep reading.

What Actually Happened

• Linux 4.4 (2016) — Commit 079096f103fa starts installing SYN_RECV request sockets into the ehash table. From here on, request sockets get processed without holding the listener lock. That's the seed of the race.
• October 5, 2026 — A kernel maintainer commits the fix (e3f33b0a1d89), ten days before the CVE goes public. Credited to Anthropic researcher Xinyang Ge.
• October 15, 2026 — CVE-2026-98432 is published by the kernel's own CVE team.
• October 16–17, 2026 — Debian ships fixes: trixie first (6.12.113-1), then bookworm (6.1.190-1). Oracle patches its UEK kernels the same window.
• October 24, 2026 — Amazon ships kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251). The kernel CVE team adds the 9.8 CVSS score to the record nine days after the initial publish.
• October 27, 2026 — Anthropic publishes its Frontier Red Team write-up detailing the exploit chain. Red Hat's own bulletin later cites this post as a reference.
• October 29, 2026 — The Go Security Team posts guidance, because MPTCP has been on by default for Go listeners since Go 1.24. Amazon ships the kernel6.12 fix.
• October 30, 2026 — Red Hat publishes RHSB-2026-016, rating the flaw Critical (9.8) and shipping an nftables mitigation — a reversal from the Moderate 5.9 rating on its own CVE page days earlier, and a reversal of its earlier "no usable mitigation" stance.

That scoring whiplash is worth sitting with for a second. On October 29, Red Hat's CVE page said Moderate (5.9). Its machine-readable VEX advisory said Important (8.1). Its internal bug tracker said Medium. Within 48 hours, all three converged on Critical.

The Bug, In Plain English

It's a race condition

A race condition happens when two operations need to happen in a specific order, but nothing in the code enforces that order.

Think of a restaurant table getting bussed while the guest is still eating. The waiter clears the plate. The guest reaches for the next bite — and either grabs air, or worse, grabs a plate that's already in the trash with food that's no longer what they think it is.

The kernel has thousands of these tables and thousands of waiters, all moving fast. Normally a lock — basically a "one waiter at a time" sign — keeps this from happening. For this specific table, that sign got taken down in 2016.

It's also a use-after-free

A use-after-free is when a chunk of memory gets freed and reused while something else still holds a pointer to it.

Picture a library book getting returned. The librarian stamps it available and hands it to the next patron. Except the first patron is still reading their copy — and it turns out to be the exact same physical book, with the new patron now highlighting pages under the first patron's fingers.

In this bug, the "book" is a block of memory holding IP options — small extras attached to an incoming TCP connection request, like Record Route or Timestamp.

Step by step, what goes wrong

1. A client sends a SYN packet (a TCP connection request) carrying IPv4 IP options.
2. The kernel finishes the handshake and hands the IP options block to the new connection's socket — by pointer, not by copy.
3. The client (or an attacker) retransmits the original SYN. A different CPU picks it up and starts building a reply, reading that same options block.
4. Meanwhile the new socket gets torn down. The kernel frees the options block.
5. The other CPU is still reading it. It's now reading freed memory.

What that buys an attacker

• Crash the box. The easy outcome. A lost race just fails one connection, so an attacker can retry forever without raising any alarms.
• Leak kernel memory. If the freed block gets reused for the right data, the reply packet carries kernel memory back to the attacker. One leaked kernel address is enough to defeat KASLR, the mechanism that randomizes where the kernel sits in memory.
• Run commands as root. Anthropic's exploit does this in two stages: leak a kernel address (48 minutes in their test run), then overwrite a function pointer with the address of staged payload code. When the kernel calls that pointer, the payload runs a shell command as root — another 5 minutes.

Why IPv6 mostly dodges this

The kernel copies the options for IPv6 connections instead of handing over a pointer. You can't free a copy out from under someone else. There's a narrower version of the same race in an IPv6 path (via CALIPSO request-socket migration), and the kernel team says a separate patch is coming for that.

Under the Hood

The vulnerable function is tcp_v4_syn_recv_sock(), which finalizes a new IPv4 TCP connection:

/* Simplified from the patch description */
newinet->inet_opt = ireq->ireq_opt;   /* ownership transfer, no copy */

The request_sock's ireq_opt (an ip_options_rcu block) now has exactly one owner: the child socket. But the old request socket can still be alive and running on another CPU.

The read side

When a retransmitted SYN shows up for the same request socket, tcp_check_req() triggers tcp_v4_send_synack() and inet_csk_route_req() on a different CPU. Those paths read ireq->ireq_opt under rcu_read_lock() only:

tcp_v4_send_synack()   /* reads ireq_opt under rcu_read_lock() */
inet_csk_route_req()   /* same */
ip_build_and_send_pkt()
ip_options_build()     /* reads opt->optlen twice — UAF here */

RCU normally guarantees the memory won't be freed mid-read — but only if the free side also plays by RCU rules. It doesn't:

inet_sock_destruct()      -> kfree(inet_opt)        /* plain free */
tcp_v4_reqsk_destructor() -> kfree(ireq_opt)        /* plain free */

TCP child sockets don't carry SOCK_RCU_FREE. A plain kfree() doesn't wait for an RCU grace period. ip_options_build() then dereferences opt->optlen on memory that's already back in the allocator. That's the use-after-free.

Why the listener lock doesn't save you

Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets get processed without the listener lock held. Nothing stops the child socket from being torn down mid-SYNACK-build.

The SYNACK timer path itself is actually safe — it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. The hole is in the non-timer path.

The second path: socket migration

net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program, clones request sockets during listener shutdown:

reqsk_timer_handler()
  -> inet_reqsk_clone()      /* clone shares ireq_opt with original */
  -> reqsk_migrate_reset()   /* clears pointer in the old one only */

The old request socket and its clone end up sharing one ireq_opt. Another CPU holding a reference to the old socket can still be mid-SYNACK or mid-child-creation when the clone gets freed — and tcp_v4_reqsk_destructor() uses a plain kfree() there too.

The fix

One idea, applied in two places: let RCU do its job.

- inet_sock_destruct()       -> kfree(inet_opt)
+ inet_sock_destruct()       -> kfree_rcu(inet_opt, rcu)

- tcp_v4_reqsk_destructor()  -> kfree(ireq_opt)
+ tcp_v4_reqsk_destructor()  -> kfree_rcu(ireq_opt, rcu)

Readers already run under rcu_read_lock(). Other code paths that replace inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()) already use kfree_rcu(). The destructors were just the stragglers.

Kernel CVE record, straight from the source:

• Introduced in: Linux 4.4, commit 079096f103fa
• Fixed in: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
• Fix commit: e3f33b0a1d89d738e2b913dab519226eaf76e15b (landed in 7.3-rc7)
• Affected files: net/ipv4/af_inet.c, net/ipv4/tcp_ipv4.c
• Reporter: Xinyang Ge (Anthropic)

The exploit chain

Anthropic's proof of concept runs in two stages:

Stage 1 — beat KASLR. The race tricks the kernel into reading an attacker-influenced length field, copying extra bytes into the reply, and sending them back. One reply with a kernel pointer in it, and the attacker knows the kernel's address space layout. Measured time: 48 minutes.

Stage 2 — hijack control flow. The same UAF overflows a buffer and overwrites a callback pointer with the address of payload code the attacker already staged in kernel memory "via an ordinary protocol feature." When the kernel invokes that callback, the payload chains through existing kernel functions and lands on an attacker-chosen shell command running as root. Measured time: 5 more minutes.

The part that makes this genuinely nasty: a lost race only fails that one handshake. No crash, no log spam, no service blip anyone would notice. The attacker just retries, indefinitely, until it lands.

Anthropic has not published the exploit code, the kernel version it was tested against, or the full target configuration.

Why the Severity Scores Disagree

Four different ratings, one bug, in the same week:

Every metric lines up except attack complexity:

• Low (kernel team): both halves of the race are attacker-controlled. Send a SYN with IPv4 Record Route or Timestamp options, retransmit it, try to win the race. No special network position needed.
• High (vendors): reliably winning a cross-CPU memory race takes precise timing. Red Hat's original CVE page said the most likely outcome is a crash, with memory corruption "possible in theory," and that no confidentiality or integrity impact had actually been demonstrated.

Red Hat's reversal to Critical is the real story here. Its bulletin lays out the reasoning plainly: unauthenticated remote attacker, kernel memory corruption or a crash, ordinary IPv4 TCP traffic, no privileges or user interaction required, and broad exposure because — in Red Hat's own words — TCP is fundamental to nearly all networked services. Reliable code execution still needs precise heap control, but Red Hat no longer treats that as a reason to downgrade the rating.

Where Your Distribution Stands

Status consolidated from vendor pages, checked October 30–31, 2026:

AlmaLinux and Rocky aren't on vendor-published advisories as of this writing — both rebuild from RHEL sources, so expect them to trail whatever Red Hat ships by the usual rebuild lag rather than get ahead of it. If you're on either, your uname -r check matters more than a CVE page right now.

If you build your own kernel, the fix is in every stable branch listed above. The kernel CVE team recommends updating to the latest stable release and is explicit that the kernel community does not support cherry-picking this fix individually.

MPTCP, Go, and Why One Mitigation Is Fragile

The CVE record never mentions multipath TCP. The description, the patch, and the kernel's own advisory all describe a plain IPv4 TCP race, full stop.

The MPTCP connection comes from Anthropic's post, which says its exploit targets "Linux servers with a multipath TCP listener." MPTCP lets one connection use several network paths at once, and on Linux an application has to request it explicitly when it opens a socket.

Except since Go 1.24, Go programs request MPTCP by default on the sockets they listen on. That's exactly why the Go Security Team put out guidance on October 29:

# Runtime: disable MPTCP by default for this program
GODEBUG=multipathtcp=0 ./your-server

// Build time: add to main module's go.mod
godebug multipathtcp=0

Code that calls SetMultipathTCP() overrides both of those.

The Go team is blunt about the limits here:

• Turning MPTCP off program by program is fragile. One MPTCP listener left exposed leaves the whole system vulnerable.
• It assumes the working exploit specifically depends on MPTCP. The underlying bug is not MPTCP-specific. A box with zero MPTCP listeners can still be hit by a similar attack.
• The real fix is a patched kernel. Everything else is a stopgap.

Mitigation: Drop IPv4 TCP Packets With IP Options

Red Hat's RHSB-2026-016 ships an nftables rule. The exploit needs an incoming SYN carrying IPv4 IP options (Record Route or Timestamp), and those options live in the IPv4 header — meaning the header runs longer than the standard 20 bytes. TCP options live in the TCP header and aren't touched by this rule.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Apply it:

sudo nft --check --file cve_2026_98432.nft
sudo nft --file cve_2026_98432.nft
sudo nft list table inet cve_2026_98432

Remove it once your kernel is patched:

sudo nft delete table inet cve_2026_98432

Fair warning: this is a partial mitigation. Red Hat's own language is that it "reduces exposure to this vulnerability but cannot fully prevent it." Check the rule against your own traffic before you deploy it — some routing and timestamping tools legitimately use IPv4 IP options, and this rule will drop them too. Test somewhere that isn't production first. The only real fix is a patched kernel.

Neither Ubuntu nor any other vendor besides Red Hat has published a mitigation as of October 30.

What To Do Now

1. Patch if your distro already has a fix. Debian, Oracle Linux, SUSE Linux Micro 6.2 / openSUSE Leap 16.0, and Amazon Linux (kernel6.18, kernel6.12) have updates out. Install and reboot.
2. On Ubuntu or RHEL (and AlmaLinux/Rocky): apply the nftables mitigation and keep an eye on your vendor's CVE page. Both list the fix as in progress with no committed date.
3. Find MPTCP listeners on your hosts with ss -M -l. For Go services, weigh whether GODEBUG=multipathtcp=0 is acceptable for you, knowing it doesn't fully close the hole.
4. Running a self-built kernel? Move to the latest stable release. Fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, or 7.3.
5. No known exploitation in the wild — yet. As of October 29, no vendor advisory, the CVE record, or Anthropic's own post reports active attacks using this flaw, and it's not in CISA's Known Exploited Vulnerabilities catalog as of the October 28 update.

How Reliable Is This

I pulled this from The Hacker News' coverage and checked the claims directly against primary sources before writing this up:

• CVE record and the 9.8 score — confirmed against the kernel.googlesource.com CVE mbox: CVSS v3.1: 9.8 CRITICAL, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
• Bug mechanics — Ubuntu's and Debian's trackers quote the full upstream patch description: ownership transfer without a copy, the UAF in ip_options_build(), IPv6 unaffected by this specific issue.
• Fixed versions and timeline — identical across the kernel mbox, Ubuntu's tracker (published Oct 15, updated Oct 30), and Debian's tracker.
• Anthropic's post (Oct 27) — CVE ID, MPTCP listener targeting, root RCE, the 48-minute leak, the 5-minute escalation, "patched upstream and backported to all maintained stable kernel branches," Xinyang Ge credited as contributor. All of it checks out.
• Debian and Amazon package versions — exact match, right down to the advisory IDs.

Two things changed since this story first broke:

1. Red Hat now rates the flaw Critical (9.8) per RHSB-2026-016, not the earlier Moderate 5.9 / Important 8.1.
2. Red Hat now ships a mitigation, which directly contradicts its earlier "no usable mitigation" position.

One thing I couldn't independently verify: the Go golang-announce post itself — the linked Google Groups thread returns "cannot be found" as of this writing. Treat the GODEBUG=multipathtcp=0 guidance as reported secondhand until that announcement is reachable directly.

Quick Vocabulary Reference

For anyone who wants the jargon decoded in one place before diving back into the comments section or your own distro’s advisory page:

Race condition — a bug that only shows up when two operations run in an order the code didn’t expect. Nothing enforces “this happens first,” so sometimes it doesn’t.
Use-after-free (UAF) — code keeps using a pointer to memory that’s already been freed and potentially handed to something else. Classic memory-corruption bug class.
RCU (Read-Copy-Update) — a kernel synchronization mechanism that lets readers access data without locks, as long as anything that frees that data waits for a “grace period” first so no reader is caught mid-read. This bug exists because the free side skipped that wait.
kfree() vs kfree_rcu() — kfree() frees memory immediately. kfree_rcu() defers the free until it’s safe for RCU readers. The fix here is swapping the former for the latter.
KASLR (Kernel Address Space Layout Randomization) — a defense that randomizes where the kernel sits in memory each boot, so an attacker can’t hardcode addresses. Leaking even one kernel pointer defeats it.
SYN / SYN_RECV — the first packet in a TCP handshake, and the kernel state a connection sits in while that handshake is still being completed.
Request socket (request_sock) — a lightweight, temporary kernel object representing a connection that’s mid-handshake, before it becomes a full child socket.
ehash table — the kernel’s hash table of active TCP sockets, used to quickly look up a connection by its address/port tuple.
IP options — optional extra fields in the IPv4 header (like Record Route or Timestamp) that aren’t present in most normal traffic but are perfectly legal to send.
MPTCP (Multipath TCP) — a TCP extension that lets a single connection use multiple network paths at once. Must be explicitly requested by an application — except on Go, where it’s been default-on since Go 1.24.
CVSS (Common Vulnerability Scoring System) — the standard 0–10 severity scale vendors use to rate vulnerabilities. This bug is a case study in how differently vendors can read the same metrics.
nftables — the modern Linux packet-filtering framework (successor to iptables), used here to build the stopgap mitigation rule.
CISA KEV (Known Exploited Vulnerabilities) catalog — CISA’s running list of vulnerabilities confirmed to be under active exploitation in the wild. This CVE isn’t on it as of this writing.

Sources

• Kernel CVE record (mbox): kernel.googlesource.com/.../cve/published/2026/CVE-2026-98432.mbox
• Upstream fix commit: git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b
• Anthropic, "Discovering and exploiting vulnerabilities in critical, real-world software with Claude," Oct 27, 2026
• Red Hat Security Bulletin RHSB-2026-016, Oct 30, 2026
• Ubuntu CVE-2026-98432 — ubuntu.com/security/CVE-2026-98432
• Debian security tracker — DSA-6568-1, DLA-4841-1, DLA-4850-1
• Amazon Linux ALAS2023-2026-3251, ALAS2023-2026-3335
• The Hacker News, "Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions," Oct 29–30, 2026