Most security bugs live in an app. You patch the app, you move on. This one lives underneath every app on the box, and that is why I am spending my Sunday on it.<\/p>\n
The bug is CVE-2026-98432, a use-after-free flaw in the Linux kernel’s IPv4 TCP handling \u2014 the code that runs when a server accepts a new connection, before any application sees a byte. The Linux kernel’s own CVE authority scores it 9.8 out of 10, Critical. On October 30, Red Hat raised its rating to Critical at 9.8 as well and published emergency bulletin RHSB-2026-016. When Red Hat moves a kernel bug to 9.8 and rushes out a bulletin, I pay attention.<\/p>\n
When a client opens a TCP connection, its first packet can carry IPv4 options. The kernel saves them, hands them from the half-open connection to the finished socket without copying them, and can free that memory while another processor is still reading it. That is a use-after-free. In the kernel it can mean leaked or corrupted memory, a crash \u2014 or, as Red Hat puts it, remote code execution.<\/p>\n
Red Hat says a remote attacker needs no privileges and no user interaction, though precise timing is required, because this is a race. Anthropic, whose researcher Xinyang Ge reported the bug, showed why that caveat should not comfort anyone. In its October 27 write-up, Anthropic said its Claude model built a working proof of concept against a server with a multipath TCP (MPTCP) listener: about 48 minutes to leak a kernel pointer, then about five more minutes to run commands as root. A lost race only fails the handshake, so an attacker can try again.<\/p>\n
Do not let the MPTCP detail shrink this. The Go Security Team warned on October 29 that the bug is not specific to MPTCP, and similar attacks may be possible without an MPTCP listener. Go matters because Go 1.24 enables MPTCP by default for listen sockets on Linux \u2014 so plenty of Go servers have exactly the listener shape the demonstration used, whether their owners chose it or not.<\/p>\n
The flaw goes back to Linux 4.4. Upstream fixed it in October \u2014 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, plus 7.3 in mainline. The fix is tiny: wait for readers to finish before freeing that memory.<\/p>\n
Here is the awkward part. Almost nobody runs an upstream kernel \u2014 we run our distribution’s kernel, and status is split. As of checks published October 31 and November 1: Debian has fixed kernels out, Amazon Linux lists its families as fixed, and SUSE and Oracle Linux have fixes for parts of their lineups. AlmaLinux has patched kernels in testing, not production. And the two names most servers run \u2014 Ubuntu and Red Hat Enterprise Linux \u2014 had no fixed kernel yet. Ubuntu showed every release as vulnerable, with work in progress. Red Hat listed RHEL 8, 9, and 10, plus OpenShift, as affected, fixes expedited, none released.<\/p>\n
Containers do not save you. Every container shares the host’s kernel, so rebuilding an image changes nothing. On Kubernetes, this is a node problem, not a pod problem.<\/p>\n
I am not calling this an active disaster, because the sources do not. As of November 1, the trackers I read found no confirmed in-the-wild exploitation, Anthropic has not published its exploit code, and the bug was not in CISA’s Known Exploited Vulnerabilities catalog in the feed checked October 31.<\/p>\n
But a remotely reachable 9.8 in the handshake path, with a demonstrated path to root and the two biggest server distributions still waiting on packages, is exactly the window attackers like \u2014 the gap between public details and your distro’s kernel landing.<\/p>\n
First, check what is running, not what is installed: Second, check for the demonstrated exposure: Third, if your distro has the fix, install it and reboot. A kernel update does nothing until the machine boots into it \u2014 a box that updated but never rebooted is still running the vulnerable kernel.<\/p>\n Fourth, if your distro has no fix yet, use the stopgap honestly. Red Hat’s bulletin publishes an nftables rule dropping incoming IPv4 TCP packets carrying IP options \u2014 headers longer than the standard 20 bytes. Normal TCP almost never carries IP options, so for most servers this costs nothing. Red Hat is clear: the rule reduces exposure but cannot fully prevent the vulnerability, can disrupt workloads that really use IP options, and does not replace a fixed kernel. Turning MPTCP off if you do not use it removes the setup the demonstration needed \u2014 a reduction, not a fix.<\/p>\n My rule is simple: patch the host, not the app. Check your kernels today, put the stopgap on boxes still waiting, and reboot into the real fix the day your distro ships it.<\/p>\n Sources: Atlas, “Linux’s October 2026 TCP Use-After-Free: CVE-2026-98432” \u2014 atlasum.net\/blog\/cve-2026-98432-linux-ipv4-tcp-uaf<\/a>; BytesNation, “CVE-2026-98432: A Remote Root Bug in the Linux TCP Handshake” (updated November 1, 2026) \u2014 bytesnation.com\/blog\/cve-2026-98432-linux-tcp-handshake-use-after-free<\/a>; NeoTeo, “Linux TCP flaw CVE-2026-98432: vendor updates” (November 1, 2026), reporting Red Hat’s CVE page and bulletin RHSB-2026-016, Anthropic’s October 27 account, and the Go Security Team’s October 29 guidance \u2014 neoteo.com\/en\/red-hat-rates-cve-2026-98432-critical-and-limits-its-filter<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Most security bugs live in an app. You patch the app, you move on. This one lives underneath every app on the box, and that is why I am spending my Sunday on it. The bug is CVE-2026-98432, a use-after-free flaw in the Linux kernel’s IPv4 TCP handling \u2014 the code that runs when a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-163","post","type-post","status-publish","format-standard","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/163","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/comments?post=163"}],"version-history":[{"count":1,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/163\/revisions"}],"predecessor-version":[{"id":164,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/163\/revisions\/164"}],"wp:attachment":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/media?parent=163"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/categories?post=163"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/tags?post=163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}uname -r<\/code> on every Linux host, including container hosts and Kubernetes nodes. Compare it against your distribution’s tracker for this CVE \u2014 not the upstream numbers, because distro kernels backport fixes under their own versions.<\/p>\nsudo ss -Mlnp<\/code> lists MPTCP listeners. If something is listed, that host goes to the top of your patch list, and that listener should not sit open to the internet while you wait.<\/p>\n