What CVE-2026-98432 means for Linux servers

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake that a remote, unauthenticated attacker can reach over the network. The kernel CNA published it on October 15, 2026, and scored it CVSS 3.1 9.8 - Critical - with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No privileges and no user interaction are needed; one crafted packet can trigger it during the handshake, before any application code runs. Kernel CNA record

This matters to anyone running Linux servers, not just kernel engineers. Web servers, SSH, databases, load balancers, and Kubernetes nodes all accept IPv4 TCP connections, and the vulnerable path runs inside the kernel before authentication. Because containers report the host kernel, patching a container image does not help - the host must be patched and rebooted. As of October 31, 2026, Ubuntu and Red Hat had not shipped fixed kernels, while Amazon, Oracle, Debian, SUSE, and AlmaLinux had patches in various stages.

What CVE-2026-98432 is

The CVE record, titled "ipv4: free inet_opt and ireq_opt after an RCU grace period," comes from the Linux kernel CNA at kernel.org and was published October 15, 2026. NVD still showed "Received" with no independent NIST score as of late October, so the 9.8 is the CNA's score for now. It is a memory-safety bug: the kernel frees TCP/IP option structures while another CPU may still read them during a SYN retransmission.

How the race condition works

1. A client sends a SYN to a listening IPv4 socket. tcp_v4_syn_recv_sock() creates a request socket and attaches IP options to it.
2. Ownership of those options transfers to the child socket without being copied.
3. A retransmitted SYN for the same request socket arrives while the first handshake is in flight; tcp_check_req() processes it and sends a SYNACK.
4. tcp_v4_send_synack() and inet_csk_route_req() read the options under rcu_read_lock() only.
5. inet_sock_destruct() and tcp_v4_reqsk_destructor() free the options with a plain kfree(). TCP child sockets do not use SOCK_RCU_FREE, so a reader can touch freed memory - a use-after-free inside ip_options_build().

The flaw lives in net/ipv4/af_inet.c and net/ipv4/tcp_ipv4.c. IPv6 is not affected by this issue because tcp_v6_syn_recv_sock() duplicates options. The upstream fix commit by Eric Dumazet converts two kfree() calls to kfree_rcu(), which matches the RCU grace-period pattern named in the CVE title.

How we checked this

ToolSura has not independently reproduced CVE-2026-98432 or confirmed in-the-wild exploitation. The details above come from the kernel CNA record, the upstream fix commit, and distributor advisories. Where a vendor page conflicts with another, we list both scores and note the date each was observed, because a score that moved from 5.9 to 9.8 in two weeks tells you more about the scoring process than about the bug itself.

We did verify that the fix commit e3f33b0 converts two kfree() calls to kfree_rcu(). We could not independently verify any public proof-of-concept exploit, and none of the code repositories referencing the CVE are linked or confirmed by primary advisory sources. CISA KEV catalog, checked October 29, did not list it.

Who is affected right now

The bug affects Linux 4.4 and up through the unpatched ranges. Fixed stable releases shipped October 11-18, 2026: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3. Upstream branches before 5.10 are end-of-life and get no upstream fix - only distro backports.

Why the vendor scores disagree for CVE-2026-98432

The kernel CNA scored 9.8 Critical. Red Hat's page showed 5.9 Moderate (or 8.1 Important in its advisory file) before raising to Critical 9.8 on October 30. Amazon, Oracle, and SUSE list 8.1; Ubuntu lists High / 9.8. These are vendor VEX scores, not contradictions - each distributor weighs its own kernel build and backlog. Trust the score your own distributor publishes, and read its advisory directly.

The two-week gap between Red Hat's initial Moderate rating and its final Critical rating is worth noticing. A CVSS score is supposed to describe the vulnerability, not the vendor's patch schedule. When a score jumps that far without a change to the underlying bug, the number is reflecting internal prioritisation, not new technical evidence. Treat your distributor's current score as the authoritative one, but do not treat a late jump to Critical as proof that the exploit became easier in the meantime.

What you can do before you can reboot

Installing a patched kernel is not enough - the host must reboot into it. Until then, Red Hat documents an nftables rule that drops inbound IPv4 TCP packets carrying IP options (ip hdrlength > 5), with an equivalent iptables raw/PREROUTING rule. It works alongside firewalld and is safe to repeat; remove it after patching. It does not fix the kernel, traffic between containers on one host can bypass it, and it must not be used on CIPSO/NetLabel networks, where IPv4 options carry labels.

Exact nftables rule:

nft add rule inet filter input ip hdrlength > 5 drop

Exact iptables equivalent:

iptables -t raw -I PREROUTING -p tcp -m ipoptions --ipoption ! 0 -j DROP

If you do not use multipath TCP, turn it off (net.mptcp_enabled = 0; per-namespace, so containers need it too). The Go team calls GODEBUG=multipathtcp=0 a fragile mitigation, and Go 1.24 enables MPTCP listeners by default where the kernel allows it.

How to verify the patch took effect

After applying a patched kernel and rebooting, confirm you are running the fixed version:

uname -r

The output should match or exceed one of the fixed stable releases listed above (for example, 6.1.190 or later on the 6.1 LTS line). On container hosts and Kubernetes nodes, check the host kernel, not the container image - uname -r inside a container reports the host kernel.

To test whether the nftables mitigation is active before you reboot:

nft list ruleset

Look for the ip hdrlength > 5 drop rule in the input chain. Remove it after patching, since it can break CIPSO/NetLabel networks and container-to-container traffic on the same host.

Multipath TCP: required for the bug, or not?

No. Anthropic's lab exploit was built against servers with an MPTCP listener, but the bug itself is not MPTCP-specific. The Go Security Team notes that systems with no MPTCP listeners may still face similar attacks, and neither the CVE record nor the fix commit mentions MPTCP. MPTCP simply makes the exploitable setup more common - Go 1.24 turns it on by default for Linux listen sockets.

Has CVE-2026-98432 been exploited in the wild?

No confirmed in-the-wild exploitation. CISA's Known Exploited Vulnerabilities catalog did not list it (catalog 2026.10.28, checked October 29). Anthropic says its Claude model wrote a remote root exploit - about 48 minutes to leak a kernel pointer, roughly five more minutes to reach shell execution - but the exploit is unpublished. ToolSura could not independently verify any public proof-of-concept, and none are confirmed by primary advisory sources. Treat any claimed PoC as unverified.

Related Tools & Further Reading

• SSL checker - verify your TLS chain and certificate validity.
• Security tools - related web utilities.
• Kernel CNA record - the CVE-2026-98432 advisory from the Linux kernel CNA.
• Fix commit e3f33b0 - Eric Dumazet's fix converts two kfree() calls to kfree_rcu().
• NVD entry - showed "Received" with no independent NIST score as of late October.
• oss-security disclosure thread - Go Security Team and distributor discussion.
• CISA KEV catalog - checked October 29; CVE-2026-98432 was not listed.
• Red Hat security advisory - RHEL 8/9/10 affected, no fix yet as of Oct 31.
• Ubuntu security notices - every release listed "Vulnerable"; no security notice published.