Vulnerabilities

Red Hat published security bulletin RHSB-2026-016 on October 30 for CVE-2026-98432, a use-after-free in the Linux kernel's IPv4 TCP connection setup code. It rates the bug Critical for Red Hat Enterprise Linux (RHEL) 8, 9 and 10 and OpenShift Container Platform, with RHEL CoreOS, OpenStack Platform and Virtualization affected through the shared kernel. Any host that accepts inbound IPv4 TCP connections reaches the vulnerable code, no login needed. Red Hat says it is "expediting the release of fixes" but had not shipped a kernel at the time of writing.

The bug dates back to Linux 4.4, so almost every supported distribution carries it. Debian, AlmaLinux (in testing), Oracle Linux and SUSE have kernels; RHEL and Ubuntu do not. On the hosting side, Akamai's status page for its Compute platform (formerly Linode) said on October 31 that it was "deploying mitigations for the underlying known attack vector", and told customers to install their distribution's update once it exists. If you run Linux servers that accept connections from the internet, plan a kernel update and reboot for them now, and use the interim filter below on RHEL and Ubuntu hosts until packages arrive.

How it works

A TCP connection starts with a three-way handshake: the client sends SYN, the server answers SYN-ACK, the client sends ACK. A SYN can carry IPv4 options such as Record Route or Timestamp, which sit in the IP header and make it longer than the usual 20 bytes. The server keeps a copy of those options with the pending connection, called a request socket, so it can echo them in its SYN-ACK.

When the handshake completes, the kernel hands that options buffer to the new connection's socket without duplicating it. If the client retransmits its SYN at the same moment and another CPU picks it up, that CPU starts building a SYN-ACK from the same buffer. If the new connection is closed and its socket freed first, the destructors inet_sock_destruct() and tcp_v4_reqsk_destructor() release the options with a plain kfree(). The other CPU is still reading them, in ip_options_build(). That read of freed, possibly reused memory is the use-after-free.

The syncookie ACK path can reach the same freed buffer, and so can request socket migration when net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in use (both off by default). The upstream fix, commit e3f33b0a1d89, swaps kfree() for kfree_rcu(), which waits for an RCU (read, copy, update) grace period, the point after which no reader can still hold the pointer. IPv6 copies options instead of sharing them and is not affected by this issue.

The kernel CVE team, Red Hat and Ubuntu score it CVSS 9.8: network reachable, no privileges, no user interaction. Some distributions score it 8.1 instead, rating attack complexity high because the attacker has to win a timing race. A lost race costs the attacker one failed connection, not a crashed server, so they can keep retrying.

What attackers are doing

No vendor, CERT or the kernel CVE team has reported exploitation in the wild, and the CVE was not in the CISA Known Exploited Vulnerabilities catalog as of October 30. The upstream fix landed in early October, and the kernel CVE team published the CVE record on October 15.

The urgency comes from Anthropic, which reported the bug and said on October 27 that its AI model had built an exploit giving remote root on Linux servers running a Multipath TCP (MPTCP) listener. It has not published the exploit. CloudLinux's kernel team says it could not reproduce the remote root claim; with artificial delays it triggered a memory error, which is a long way from code execution. Treat the exploit as plausible but unverified.

MPTCP matters because Go programs built with Go 1.24 or later open MPTCP listen sockets by default on Linux. The Go security team warned on October 29 that Go servers are a likely exposure point, and also that the underlying bug is not specific to MPTCP, so hosts without MPTCP listeners can still be attacked.

What to do

1. Install a fixed kernel where one exists and reboot. Upstream fixed stable releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Distribution status at the time of writing:

2. Confirm the running kernel has the fix. A kernel installed but not booted protects nothing. On RPM systems, rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432 should be above zero; run the same command with CVE-20 as a control so an empty changelog does not fool you.

3. If you cannot patch today, drop IPv4 TCP packets that carry options. Red Hat's bulletin gives an nftables table named inet cve_2026_98432 with a chain on the input hook at priority -310 and the rule ip protocol tcp ip hdrlength > 5 counter drop. The hdrlength field counts the header in 4-byte words, so anything above 5 carries options. Validate the file with nft --check --file before loading it. Red Hat says this reduces exposure but cannot fully prevent exploitation. AlmaLinux adds that the rule does not survive a reboot, that traffic between containers on the same host may bypass it, and that networks using CIPSO or NetLabel labelling should not use it. Remove it with nft delete table inet cve_2026_98432 once the new kernel is running.

4. Find MPTCP listeners. Check sysctl net.mptcp.enabled and list listeners with ss -Mltn. For Go services, GODEBUG=multipathtcp=0 in the environment or godebug multipathtcp=0 in go.mod turns MPTCP off. Treat this as a supplement to the packet filter: CIQ found a plain TCP listener with MPTCP disabled still answered a SYN carrying Record Route.

5. Check that request migration is off: sysctl net.ipv4.tcp_migrate_req should print 0 unless you deliberately use it.

6. Look for signs of attempts. No indicators of compromise have been published. Search kernel logs and crash dumps from internet-facing hosts for oops or KASAN reports that mention ip_options_build. Once the nftables rule is loaded, nft list table inet cve_2026_98432 shows its packet counter; legitimate traffic rarely carries IP options, so a climbing count on a public host deserves a look at the sources. Quiet logs prove little: a lost race leaves no crash.

7. On Akamai Compute and other clouds, provider-side mitigation covers the hosting platform, not your guest kernel. Akamai's status page told customers to apply upstream OS updates to their workloads. Ask other hosting suppliers when their own hosts will reboot onto a fix.

Plan for the gap between CVE and package

This CVE was public on October 15, but most teams heard about it on October 27 when the exploit claim landed, and RHEL still had no package three days after that. The upstream description talks about a crash or memory corruption; the remote root claim arrived 12 days after the CVE. Keep an inventory of internet-facing hosts with the kernel stream each one runs, and a tested nftables template on hand, so exposed hosts get a filter the day a bulletin lands.

Our safeguarding and hardening team builds those kernel and firewall baselines, and our platform and cloud engineering team runs patch and reboot rollouts across fleets and Kubernetes nodes. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Red Hat, RHSB-2026-016, Red Hat, CVE-2026-98432, Ubuntu, CVE-2026-98432, Debian security tracker, AlmaLinux, CloudLinux, CIQ knowledge base, Go security team via oss-security, Akamai Compute status, CSO Online, Rescana.