Linux Kernel CVE-2026-98432: Critical TCP Use-After-Free, No RHEL or Ubuntu Fix Yet

CVE-2026-98432 is a race condition in the Linux kernel's IPv4 TCP handshake code that can make the kernel use memory it has already freed. The Linux kernel CVE team, which assigns CVEs for the kernel, published it on 15 October 2026 and on 24 October scored it CVSS 3.1 9.8, Critical: reachable over the network, with no credentials and no user interaction (kernel CVE announcement; CVE record). The fix is in every maintained upstream stable kernel.

Distributions score it lower. Red Hat, Oracle and SUSE give 8.1 and Amazon 7.0, all rating the race hard to win, and Red Hat's own published data ranges from 5.9 to 8.1. No vendor, CERT or the kernel CVE team reports exploitation in the wild, and as of 29 October 2026 the CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Debian, Oracle Linux, Amazon Linux and SUSE have shipped fixed kernels for at least some releases. Red Hat Enterprise Linux and Ubuntu have not, and neither gives a date. Red Hat lists its fixes as "Fix deferred", which it says means a fix is not guaranteed. For fleets on those two distributions this is a before-patch window: the time to find exposed systems and line up the update, so it ships the day the vendor kernel does.

Technical Information

What the flaw is. According to the kernel CVE team, when an IPv4 TCP connection completes, tcp_v4_syn_recv_sock() hands the IP options stored with the pending request to the new socket without copying them. Another CPU can at the same moment be answering a retransmitted SYN for the same request and building a SYNACK from those options in ip_options_build(). If the new socket is freed first, the options are freed with a plain kfree() while still in use: a use-after-free. A similar race exists when request sockets are migrated between listeners, which only happens with net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE eBPF program. The kernel documentation lists tcp_migrate_req as disabled by default (kernel ip-sysctl documentation).

IPv6 is not affected by the main issue. The kernel CVE team says tcp_v6_syn_recv_sock() copies the options, so the first race does not apply. IPv6 has the same migration issue only for options set by CALIPSO, which the team says will be fixed in a separate patch.

Why the kernel CVE team scores it 9.8. Its scoring notes, published with the CVE record, assume an unauthenticated peer that sends a TCP SYN carrying IPv4 Record Route or Timestamp options and then resends it to race the connection being completed and torn down. The team rates attack complexity low because both sides of the race are "attacker-induced". It says a won race could send adjacent kernel memory back to the peer in the SYNACK, steer out-of-bounds kernel writes, or crash the system (CVE record).

Why distributions score it lower. Red Hat, Oracle and SUSE score 8.1 with the same vector as the kernel team except for attack complexity, which they rate high (Red Hat; Oracle; SUSE). Amazon scores it 7.0 (Amazon Linux). Red Hat's machine-readable advisory file shows 8.1 and Important, while the statement in its security data still rates it Moderate, 5.9, and says "denial of service being the practical worst case" (Red Hat VEX file; Red Hat security data). Ubuntu shows the 9.8 score and gives the issue High priority (Ubuntu). NVD has not added a score of its own.

How it was fixed. The fix frees the options only after an RCU grace period (kfree_rcu()), so other CPUs finish reading before the memory is released. The bug dates back to Linux 4.4. The fix commit credits Xinyang Ge of Anthropic as the reporter (fix commit).

What Anthropic reports. In a 27 October post, Anthropic said that after initial prompting its AI model wrote an exploit that lets a remote attacker with no credentials send packets to "Linux servers with a multipath TCP listener to run arbitrary commands as root," and named this CVE (Anthropic). It describes two stages: using the race to leak a kernel address and get past kernel address randomization, then using the same bug to take over a kernel callback. It says a lost race fails only that connection attempt rather than crashing the server, so an attacker can keep retrying; in its test, the leak took 48 minutes and command execution another five. Anthropic did not publish the exploit, the kernel version or the configuration it tested, and does not say whether servers without a multipath TCP (MPTCP) listener can be taken over the same way. Neither the CVE record nor the fix mentions MPTCP. We have not verified Anthropic's claims. MPTCP is opt-in on Linux: an application must ask for it when it opens a socket (kernel MPTCP documentation). Some software asks by default: since Go 1.24, Go's standard network listener uses MPTCP by default on Linux where it is supported (Go 1.24 release notes).

Exploitation status. No vendor, CERT or the kernel CVE team reports exploitation in the wild. Not in CISA KEV (catalog version 2026.10.28, checked 29 October 2026). No public exploit code is linked from any source we checked, and we do not link to any.

Timeline (Cyprus time):

• 2 October 2026: Fix written; committed on 6 October [fix commit].
• 15 October 2026, 15:08: Kernel CVE team publishes CVE-2026-98432 [CVE record].
• 16 October 2026: Oracle releases fixed Unbreakable Enterprise Kernel (UEK) packages [Oracle].
• 24 October 2026: Kernel CVE team adds the 9.8 score; Amazon ships a fixed Amazon Linux 2023 kernel6.18 [CVE record; Amazon Linux].
• 27 October 2026: Anthropic describes its MPTCP remote root exploit [Anthropic].
• 29 October 2026: SUSE publishes two kernel advisories and lists fixes for SLES 16.0, SLES 15 SP4 to SP6 LTSS and other releases; Amazon ships kernel6.12 for Amazon Linux 2023; Red Hat lists fixes as deferred; Ubuntu lists fixes as in progress; not in CISA KEV [SUSE; Amazon Linux; Red Hat; Ubuntu].

Affected Product Versions

Upstream, the kernel CVE team lists the flaw as introduced in Linux 4.4 and fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3 (kernel CVE announcement). Most systems run a distribution kernel, so the distribution's status is what counts. As of 29 October 2026:

Ubuntu also lists its cloud, FIPS and hardware-enablement kernels as vulnerable or in progress. Oracle's page covers its UEK kernels. Products and hosted services built on these distributions inherit the distribution's status.

Workaround and Mitigation

Red Hat says no available mitigation meets its standards for ease of use, wide applicability and stability, and none of the other vendor advisories lists one. The steps below are about getting ready and reducing exposure while you wait.

1. Patch where a fix exists. On Debian, Oracle Linux UEK, Amazon Linux 2023 kernel6.18 or kernel6.12, and the SUSE releases listed above, install the fixed kernel and reboot into it (or confirm your livepatch covers this CVE). A kernel fix does nothing until the system runs it. If you build your own kernels, the kernel CVE team recommends moving to the latest stable release rather than cherry-picking the fix.
2. Prepare RHEL and Ubuntu now. Inventory internet-facing RHEL 8/9/10, OpenShift 4 and Ubuntu hosts, starting with those that accept inbound IPv4 TCP from untrusted networks. Subscribe to the Red Hat and Ubuntu CVE pages, pre-approve the kernel update and plan reboot windows, so the fix can go out as soon as it ships (Rescana guidance).
3. Find MPTCP listeners. Anthropic's root exploit targeted servers with a multipath TCP listener. Identify services that open MPTCP sockets (including programs built with Go 1.24 or later, whose listeners use MPTCP by default) or are forced onto MPTCP (for example with mptcpize or GODEBUG=multipathtcp=1), and ask whether each one needs it. Neither Anthropic nor any vendor says that turning MPTCP off removes the risk, so treat this as narrowing exposure, not a fix (Rescana guidance).
4. Check the migration setting. Confirm net.ipv4.tcp_migrate_req is 0 (the default) and that no BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programs are loaded unless you rely on them. This closes only the second, migration-related path (Rescana guidance).
5. Consider filtering inbound IPv4 options. The kernel CVE team's scoring assumes a SYN carrying IPv4 Record Route or Timestamp options. Few internet services need inbound IP options, and some edge firewalls already drop them. Dropping inbound IPv4 packets with these options at the edge may reduce exposure, but no vendor has said it blocks the flaw, so test before relying on it (Rescana guidance).
6. Watch for crashes. Kernel crash or oops reports that mention ip_options_build, ip_build_and_send_pkt or skb_under_panic on internet-facing hosts deserve investigation. Anthropic says a lost race does not crash the server, so a quiet log is not proof of safety (Rescana guidance).

Indicators of Compromise

No vendor, CERT or the kernel CVE team has published indicators of compromise or a MITRE ATT&CK mapping for CVE-2026-98432, and we have none to add.

What we will update

We will update this post when Red Hat or Ubuntu release fixed kernels, if CISA adds CVE-2026-98432 to KEV, if any vendor or CERT reports exploitation in the wild, if NVD publishes its own score, if Anthropic or the kernel CVE team publish more detail on the MPTCP exploit path, or if a vendor publishes a supported mitigation.

Sources

• Linux kernel CVE team: CVE-2026-98432 announcement: https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98432.mbox; fix commit e3f33b0a1d89: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3f33b0a1d89d738e2b913dab519226eaf76e15b; kernel documentation, IP sysctl: https://docs.kernel.org/networking/ip-sysctl.html; MPTCP: https://docs.kernel.org/networking/mptcp.html
• Ubuntu (Canonical): https://ubuntu.com/security/CVE-2026-98432
• Red Hat: CVE page: https://access.redhat.com/security/cve/CVE-2026-98432; Bugzilla 2553390: https://bugzilla.redhat.com/show_bug.cgi?id=2553390; VEX file: https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-98432.json; security data: https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-98432.json
• Debian: security tracker: https://security-tracker.debian.org/tracker/CVE-2026-98432
• Oracle Linux: https://linux.oracle.com/cve/CVE-2026-98432.html
• Amazon Linux: https://explore.alas.aws.amazon.com/CVE-2026-98432.html; ALAS2023-2026-3251: https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3251.html; ALAS2023-2026-3335: https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3335.html
• SUSE: https://www.suse.com/security/cve/CVE-2026-98432.html
• CVE Program and NVD: https://www.cve.org/CVERecord?id=CVE-2026-98432; https://nvd.nist.gov/vuln/detail/CVE-2026-98432
• Go project: Go 1.24 release notes (MPTCP default for listeners): https://go.dev/doc/go1.24
• CISA: not in the KEV catalog as of catalog version 2026.10.28, checked 29 October 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Anthropic (reporter; claims not independently verified): "Discovering and exploiting vulnerabilities in critical, real-world software with Claude," 27 October 2026: https://www.anthropic.com/research/discovering-vulnerabilities-with-claude

Why this matters for your vendors

Most of the SaaS, hosting and managed services you rely on run on Linux, and many run RHEL or Ubuntu, which have no fixed kernel yet. Your exposure here depends on how quickly those suppliers move once the fix ships, and on what they do in the meantime.

Forward this to your TPRM owner: Four short questions for critical Linux-based SaaS, hosting and managed service suppliers (Rescana guidance):

• Which Linux distributions and kernel versions run your internet-facing services, and are any of them affected by CVE-2026-98432?
• Do any of those services expose multipath TCP (MPTCP) listeners, or use net.ipv4.tcp_migrate_req or reuseport migration eBPF programs?
• Where a fixed kernel already exists, is it installed and running; and for RHEL or Ubuntu systems, what interim controls are in place?
• Once Red Hat or Ubuntu ship a fix, how soon will you deploy it and reboot?

Working through Linux-based suppliers on questions like these? We can help you track their answers alongside the rest of their security posture. Book a demo.