--- title: "CVE-2026-98432: the Linux TCP bug with a two-line fix" url: "https://bosnadev.com/2026/11/02/cve-2026-98432-linux-tcp-bug" author: "Mirza Pašić" date: "2026-11-02" topic: "Server administration" tags: ["linux", "kernel", "security", "cve", "tcp"] summary: "Two lines fix a 9.8 Linux kernel bug in the TCP handshake. Which servers it reaches, how hard it is to exploit, and what to do until your distro's kernel ships." --- # CVE-2026-98432: the Linux TCP bug with a two-line fix > **Update, 3 November:** Red Hat has shipped fixed kernels. Ubuntu's fixes are still in testing. Details are at the end. The fix for [CVE-2026-98432](https://www.cve.org/CVERecord?id=CVE-2026-98432) changes two lines in the Linux kernel. Two calls to `kfree()` became `kfree_rcu()`. The bug has been in the kernel since Linux 4.4, released in January 2016, and the kernel CVE team scored it 9.8 because anyone who can reach a TCP port can trigger it, with no login. Anthropic says an unreleased Claude model wrote a remote root exploit for it, against servers with a multipath TCP (MPTCP) listener. I wanted to know what the two lines change and which servers an attacker can reach with it. ## Two CPUs, one set of options A TCP SYN can carry IPv4 options such as Record Route or Timestamp. The kernel keeps them in `ireq_opt` so it can answer with them in the SYN-ACK. Then: 1. The handshake completes, and `tcp_v4_syn_recv_sock()` hands the options to the new socket as `inet_opt`. It doesn't copy them. 2. A retransmitted SYN for the same request lands on another CPU. That CPU starts building a SYN-ACK from the same options while holding only `rcu_read_lock()`. 3. The connection closes, and `inet_sock_destruct()` frees the options at once with `kfree()`. 4. The second CPU is still reading them in `ip_options_build()`. That's a use-after-free. The [CVE record](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/98xxx/CVE-2026-98432.json) lists three outcomes: kernel heap memory sent back in the SYN-ACK, out-of-bounds writes in the kernel, and a crash through `skb_under_panic()`. A second route goes through request socket migration. It needs `net.ipv4.tcp_migrate_req=1` or a `BPF_SK_REUSEPORT_SELECT_OR_MIGRATE` program, and the sysctl is off by default. IPv6 connections avoid the main race because `tcp_v6_syn_recv_sock()` copies the options. ## The two lines Eric Dumazet wrote the fix, [commit e3f33b0a1d89](https://github.com/ctrliq/kernel-src-tree/commit/e3f33b0a1d89d738e2b913dab519226eaf76e15b), after Xinyang Ge of Anthropic reported the bug: ```diff --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ void inet_sock_destruct(struct sock *sk) - kfree(rcu_dereference_protected(inet->inet_opt, 1)); + kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu); --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ static void tcp_v4_reqsk_destructor(struct request_sock *req) - kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1)); + kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu); ``` `kfree_rcu()` waits for an RCU grace period before it frees the memory, so a CPU that has already started reading can finish first. The readers used RCU all along, and the other code that replaces these options already called `kfree_rcu()`. These two destructors were the exceptions. Upstream, the fix is 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. Distros backport fixes under their own version numbers, so go by your distro's advisory and not by this list. ## Which servers are exposed An attacker needs three things to reach the bug: an unpatched kernel from 4.4 on, an IPv4 TCP port they can connect to, and a path for SYN packets with IP options to get to the host. The race runs between two CPUs, so I'd expect a single-CPU machine to be safe from it. I haven't seen anyone confirm that. You don't need any special software. The bug sits in the handshake, before your web server, SSH or database sees the connection, as [AlmaLinux points out](https://almalinux.org/blog/2026-10-30-cve-2026-98432/). The known root exploit also needs an MPTCP listener, and you may have those without knowing it. Programs built with Go 1.24 or later open MPTCP listeners by default on Linux when the kernel allows it, according to the [Go security team](https://www.openwall.com/lists/oss-security/2026/10/30/1). Mattias Geniar [checked his own Ubuntu machine](https://ma.ttias.be/linux-cve-2026-98432-vulnerable-kernels/) and found 712 of them, all from Go programs he had never set up for MPTCP. The upstream default for `net.mptcp.enabled` is 1. AlmaLinux ships with it set to 0. ## How hard it is to exploit Hard. The attacker has to win a race between CPUs, and Red Hat says reliable code execution needs precise control of the kernel heap. Oracle, SUSE and Amazon rate the attack complexity high and score the bug 8.1. Anthropic hasn't published its exploit. As of 2 November, no vendor or CERT had reported attacks in the wild, and CISA hadn't added the CVE to its KEV catalogue ([Rescana's summary](https://www.rescana.com/post/linux-kernel-tcp-cve-2026-98432-use-after-free-prepare-now) collects these ratings). I still wouldn't wait. A lost race fails only that one handshake, so an attacker can retry for as long as they like. In Anthropic's test, leaking a kernel pointer took 48 minutes and getting command execution took five more. A script doesn't mind waiting that long. The kernel team rates the complexity low for that reason, since the attacker drives both sides of the race, and Red Hat now uses the same 9.8 score. Two more points kept me from relaxing. Nobody knows yet whether root is possible without MPTCP, and a crash or a heap leak doesn't need root at all. [Atlas counted](https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf) at least six public repositories that claim a race trigger or a proof of concept. I haven't looked at them. ## What I'd do on a server Install your distro's fixed kernel and reboot into it. Until you can, compare `uname -r` with your distro's advisory and check MPTCP and the migration setting: ```bash sysctl net.mptcp.enabled sudo ss -lnMp sysctl net.ipv4.tcp_migrate_req ``` [Red Hat suggests](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) dropping inbound IPv4 TCP packets that carry IP options. The rule lowers the risk without closing the hole, so try it on one machine first: ``` table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } } ``` Skip the filter if your network uses CIPSO security labels, because those travel as IP options. If you don't need MPTCP, turn it off and restart the services that listen. The setting applies to new sockets only, and each network namespace keeps its own value: ```bash echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-no-mptcp.conf sudo sysctl --system ``` That removes the setup the known exploit uses. The bug stays until you boot a fixed kernel. ## Update, 3 November Red Hat has shipped fixed kernels for its main RHEL streams. Canonical has built Ubuntu's fixes and is still testing them. ### Red Hat Red Hat put out its first errata on 1 November, a day before I wrote this post, and now rates the bug Critical at 9.8. | Product | Fixed kernel | Advisory | Issued | | ------------------------------------------- | ------------------------------- | ------------------------------------------------------------------- | ------ | | NVIDIA on RHEL 10, aarch64 | 6.12.0-265.31.el10nv | [RHSA-2026:93775](https://access.redhat.com/errata/RHSA-2026:93775) | 2 Nov | | RHEL 9.4, selected extended-support streams | 5.14.0-427.161.1.el9_4 | [RHSA-2026:94109](https://access.redhat.com/errata/RHSA-2026:94109) | 2 Nov | | RHEL 10.2 | 6.12.0-211.72.1.el10_2 | [RHSA-2026:93413](https://access.redhat.com/errata/RHSA-2026:93413) | 1 Nov | | RHEL 9.8 | 5.14.0-687.64.1.el9_8 | [RHSA-2026:93412](https://access.redhat.com/errata/RHSA-2026:93412) | 1 Nov | | RHEL 8.10 | 4.18.0-553.182.1.el8_10 | [RHSA-2026:93414](https://access.redhat.com/errata/RHSA-2026:93414) | 1 Nov | | RHEL 8 real-time | 4.18.0-553.182.1.rt7.523.el8_10 | [RHSA-2026:93415](https://access.redhat.com/errata/RHSA-2026:93415) | 1 Nov | The fix takes effect after you reboot into the new kernel. On 2 November Red Hat still listed OpenShift 4 and RHEL 9 real-time as affected, so check the advisory for the product you run. ### Ubuntu Canonical [posted its status](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) on 2 November. The LTS fixes are in the -proposed pocket for people who run their own kernel acceptance tests. Canonical is testing them on more than 2,000 certified servers and devices and hasn't given a release date. | Release | Kernel package | Status | | ------------------- | -------------- | ------------------------------------ | | 26.10 Stonking | 7.3.0-10.10 | Fixed, according to Canonical's post | | 26.04 LTS Resolute | 7.0.0-43.43 | Fix in -proposed | | 24.04 LTS Noble | 6.8.0-149.149 | Fix in -proposed | | 22.04 LTS Jammy | 5.15.0-203.213 | Fix in -proposed | | 20.04, 18.04, 16.04 | None yet | Fix pending, through Ubuntu Pro | | 14.04 Trusty | Not needed | Not affected | Canonical's post lists 26.10 as fixed, but the [Ubuntu CVE tracker](https://ubuntu.com/security/CVE-2026-98432), updated on 3 November, still shows 22.04 to 26.10 as vulnerable with work in progress. Cloud and HWE kernels have their own rows on the tracker, so look up the kernel you boot. If you test your own kernels and want the fix now, Canonical gives these steps for kernels installed through a meta-package: ```bash sudo add-apt-repository --component main --pocket proposed \ http://archive.ubuntu.com/ubuntu sudo apt update dpkg-query -W -f '${source:Package}\t${binary:Package}\n' \ | awk '$1 ~ "^linux-meta" { print $2 }' \ | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade sudo reboot ``` These packages haven't finished qualification, so put them on a test machine before production. ### Scanning [Cyber Security News reports](https://cybersecuritynews.com/linux-kernel-rce-flaw-ubuntu-fixes/) that Marcus Hutchins saw residential proxies and Russia-based VPN servers probing port 443 with MPTCP connections from 2 November, and that he suspects a link to this CVE. The same report counts about 2.1 million servers that accept MPTCP on that port. Neither the outlet nor I could open his original post, so treat the numbers with care. They count servers with MPTCP, and say nothing about how many run an unpatched kernel. The report also says nobody has published a remote code execution exploit yet, while several denial-of-service proofs of concept are public. ## References 1. CVE Program. [CVE-2026-98432 record](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/98xxx/CVE-2026-98432.json). The bug description, the 9.8 score, and affected and fixed versions. 2. Linux kernel. [Commit e3f33b0a1d89](https://github.com/ctrliq/kernel-src-tree/commit/e3f33b0a1d89d738e2b913dab519226eaf76e15b), on a GitHub mirror, and [the same commit on git.kernel.org](https://git.kernel.org/stable/c/e3f33b0a1d89d738e2b913dab519226eaf76e15b). 3. Rescana. [Linux Kernel CVE-2026-98432: Critical TCP Use-After-Free, RHEL Fixed, Ubuntu Pending](https://www.rescana.com/post/linux-kernel-tcp-cve-2026-98432-use-after-free-prepare-now). Vendor scores, exploitation status and a summary of [Anthropic's research post](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude). 4. Lilting Channel. [CVE-2026-98432 Linux TCP Use-After-Free Can Give Unauthenticated Root on MPTCP Listeners](https://lilting.ch/en/articles/linux-ipv4-tcp-options-uaf-mptcp-rce). A walkthrough of the race and the exploit stages. 5. Mattias Geniar. [CVE-2026-98432: which Linux kernels are still vulnerable](https://ma.ttias.be/linux-cve-2026-98432-vulnerable-kernels/). Distro status as of 3 November, and his MPTCP listener test. 6. AlmaLinux. [CVE-2026-98432: Patched kernels available in testing](https://almalinux.org/blog/2026-10-30-cve-2026-98432/). Impact, the MPTCP default, the migration setting and the limits of the filter. 7. Red Hat. [RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016). Affected products and the nftables rule. 8. Go Security Team on oss-security. [Protecting against CVE-2026-98432](https://www.openwall.com/lists/oss-security/2026/10/30/1). Go's MPTCP default and why turning it off is only a partial fix. 9. Atlas. [Linux's October 2026 TCP Use-After-Free](https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf). A timeline and a count of public proof-of-concept repositories. 10. Canonical. [Fixes available in -proposed pocket for CVE-2026-98432](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432), 2 November 2026. 11. Ubuntu. [CVE-2026-98432 tracker](https://ubuntu.com/security/CVE-2026-98432), updated 3 November 2026. 12. Cyber Security News. [Attackers Started Scanning in the Wild for Linux Kernel RCE Flaw, Ubuntu Releases Fixes](https://cybersecuritynews.com/linux-kernel-rce-flaw-ubuntu-fixes/), 3 November 2026.