Tuskira AdvisoryNot observedLast updatedNovember 1, 2026

CVE-2026-98432

Linux kernel IPv4 TCP use-after-free reachable by an unauthenticated peer during the handshake; public trigger code, no exploitation reported, RHEL and Ubuntu not yet fixed

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. An unauthenticated peer sends a SYN carrying IPv4 Record Route or Timestamp options, then races a retransmitted SYN against the connection being torn down. Any host running an unpatched kernel from 4.4 onward that accepts IPv4 TCP connections is in scope, whether or not it uses Multipath TCP (MPTCP). The fix is in stable kernels released in October, but Red Hat and Ubuntu have not shipped fixed kernels yet.

kernel.org, the CNA, scores it 9.8, and Red Hat agrees; SUSE and Amazon rate it 8.1. NVD has not added its own score. Public code posted on GitHub on October 30 and 31 triggers or detects the bug, and by its own READMEs none of it takes over a host. It is not on CISA's Known Exploited Vulnerabilities catalog, and no exploitation has been reported. This is not an MPTCP bug, despite how much of the coverage describes it. MPTCP matters because it is the configuration where a working exploit is claimed.

Vendor
Linux kernel (kernel.org)
Product
Linux kernel IPv4 TCP
Affected versions
Linux 4.4 and later, before 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10; 7.3 and later are fixed (kernel.org CNA record)
Vulnerable component
IPv4 TCP handshake: tcp_v4_syn_recv_sock(), inet_sock_destruct() and ip_options_build(), reached by a SYN carrying IPv4 Record Route or Timestamp options
CVSS
9.8 (kernel.org as CNA; Red Hat agrees); NVD has not added its own score. SUSE and Amazon rate it 8.1
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (kernel.org)
CWE
Use after free (per the kernel.org description); no CWE published
Exploitation
Not observed
CISA KEV added
Patch
Stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3 onward. Distro status varies; Debian 12 and 13, Amazon Linux 2 and AL2023, and most SUSE releases are fixed, RHEL 8 to 10 and Ubuntu are not yet. A fixed kernel does nothing until the host boots into it
Vendor fixResearcher advisory

Is it reachable for you?

What it is. Per the kernel.org record, tcp_v4_syn_recv_sock() hands the request socket's IP options to the new child socket without copying them, while another CPU can still be building a SYN-ACK from the same options for a retransmitted SYN. The child socket is freed with a plain kfree() in inet_sock_destruct(), and ip_options_build() then reads freed memory. The CNA's scoring notes say this can leak kernel heap contents to the peer in the SYN-ACK, allow out-of-bounds kernel writes, or panic the host. The record also describes a second, similar path through request socket migration. IPv6 is not affected by the main issue; a related IPv6 migration issue, set only by CALIPSO, gets a separate patch.

Not to be confused with. CVE-2026-46300 (Fragnesia), the Linux kernel ESP bug already on this page and on CISA KEV since October 28. It is a different bug with a different fix.

Distro status, from each vendor's tracker as of November 1, 2026.

  • RHEL 8, 9 and 10, plus OpenShift: no fixed kernel listed. Red Hat's bulletin RHSB-2026-016 (October 30) says Red Hat is expediting fixes and gives a packet-filter mitigation.
  • Ubuntu 16.04 through 26.10: vulnerable on every supported release, with fixes listed as in progress (for example 6.8.0-149.149 on 24.04 and 5.15.0-203.213 on 22.04).
  • Debian 12: fixed in 6.1.190-1 (DLA-4841-1) and linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1). Debian 13: fixed in 6.12.113-1 (DSA-6568-1).
  • SUSE: released for SLES 16.0, SLES 15 SP4, SP5 and SP6 LTSS, SLE Micro 5.3 to 5.5, SL Micro 6.2 and openSUSE Leap 16.0. SLES 15 SP7 is in QA (kernel 6.4.0-150700.53.90.1), and SL Micro 6.0 and 6.1 are still listed as affected.
  • Amazon Linux: fixed on AL2023 (kernel, kernel6.12, kernel6.18) and Amazon Linux 2 (core kernel and the 5.4, 5.10 and 5.15 extras).

Checks, in three tiers. The first decides exposure. The second and third decide priority. Run these only on hosts your organization owns.

  1. Is the running kernel unpatched? This decides exposure. uname -r shows the running kernel; compare it against the fixed stable versions or your distro's fixed package. rpm -q kernel or dpkg -l 'linux-image*' shows installed packages, and an installed fixed kernel does nothing until the host reboots into it. ss -tlnp4 lists IPv4 TCP listeners. If the kernel is unpatched and that list isn't empty, the host is in scope.
  2. Does the host have MPTCP listeners? These go first, because it is the configuration where a working exploit is claimed. Anthropic's Frontier Red Team, in an October 27 research post, says an internal model wrote a working remote root exploit against Linux servers with an MPTCP listener; the code and test configuration have not been published, and nobody has independently reproduced it. ss -Mltn lists MPTCP listeners. sysctl net.mptcp.enabled returns 1 if MPTCP sockets can be created; the upstream default is 1, and Red Hat's documentation says MPTCP is disabled by default on RHEL. Go 1.24 and later enable MPTCP by default on listen sockets, per the Go Security Team; check a binary's toolchain with go version -m <binary> and look for a multipathtcp GODEBUG setting.
  3. Is the second path open? sysctl net.ipv4.tcp_migrate_req returns 1 if request socket migration is on (the default is 0). bpftool prog list shows loaded BPF programs; look for sk_reuseport programs, which can include a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program.

Public code. Three repositories posted October 30 and 31 trigger or detect the bug. googlesky/CVE-2026-98432 is a KASAN lab reproduction that "boots a guest kernel so the patched host kernel is never the target" and adds a 5 ms delay "used for reproducibility in these repro kernels only"; it reports a use-after-free and no exploit stage. alvaroguzmancode/cve-2026-98432 says "This is a bug detector/trigger, not an exploit" and "No RCE, no KASLR leak and no write primitive are implemented." Alucard0x1/cve-2026-98432 says it "triggers the race and detects when the kernel copies bytes out of a freed ip_options_rcu object into a SYN-ACK" and "does not implement a code-execution chain."

Compensating controls until you patch

The patched kernel, booted and running, is the only fix. These reduce exposure on hosts still waiting for a fixed kernel, and each one works only under the condition at the end of its line. Test them in staging first.

  • Delivery. Drop inbound IPv4 TCP packets that carry IP options. Red Hat's bulletin RHSB-2026-016 gives an nftables rule for this, saved to a file, checked with nft --check, applied with nft --file and verified with nft list table inet cve_2026_98432; Red Hat says filtering "is not a substitute for patching." TuxCare published an equivalent rule that matches ip hdrlength != 5, says it is untested against an exploit, and notes it does not survive a reboot unless made persistent. Rui Sousa notes on oss-security that a host packet filter "can be bypassed by traffic between containers on the same host." This only helps if no legitimate clients send IPv4 options and all traffic to the host, including container-to-container traffic, passes through the filter.
  • Exploitation. Set sysctl -w net.mptcp.enabled=0 and persist it under /etc/sysctl.d/. This closes the claimed exploit path, not the underlying bug, only if nothing on the host needs MPTCP and services that already opened MPTCP listeners are restarted.
  • Exploitation. Set GODEBUG=multipathtcp=0 for Go 1.24 and later programs, or godebug multipathtcp=0 in go.mod at build time. The Go Security Team calls disabling MPTCP program by program "a fragile mitigation." This only helps if every Go listener on the host gets the setting and no code overrides it with SetMultipathTCP.
  • Exploitation. Set sysctl -w net.ipv4.tcp_migrate_req=0 and detach any BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. This closes the migration path only, and only if no service depends on request socket migration.
  • Blast radius. Boot with init_on_free=1, which zeroes memory when it is freed. Rui Sousa suggests it on oss-security as interim hardening and says plainly it "does not fix this bug." It limits what a read of freed memory can leak, only if the kernel supports it (mainline since 5.3), the host is rebooted, and you can accept a small performance cost.

The patch is the only fix. Boot a stable kernel at or above 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 or 7.2.10, or your distro's fixed package.

What to look for in logs

No vendor or researcher has published network or host indicators for exploitation of this CVE as of November 1, 2026. These are what the public code and the kernel.org record point to.

  • Inbound TCP SYNs carrying IPv4 Record Route or Timestamp options, which are rare in normal traffic, especially repeated SYNs with options from the same source.
  • SYN-ACKs leaving the host with IP options of unexpected length, which is how the Alucard0x1 PoC detects a leak.
  • Kernel oopses or panics mentioning ip_options_build, ip_build_and_send_pkt or skb_under_panic, or KASAN reports of a use-after-free in inet_csk_route_req on test kernels.
  • Unexpected reboots of internet-facing Linux hosts.

How Tuskira helps

Tuskira is an agentic cyber defense platform that connects to the 200+ security and IT tools you already run. When a new critical vulnerability lands, Tuskira answers three questions.

Is there a reachable path? For example, whether an internet-facing Linux host runs a kernel without the October stable fix and has an IPv4 TCP listener, and whether that listener is an MPTCP socket such as a Go 1.24 service.

Would your controls stop it? Tuskira tests the controls you already run, such as your WAF, firewall rules and EDR, against the path.

Can you close the gap now? Quell stages the compensating control change through your existing tools, with your approval, then re-tests to confirm the path is closed.

The vendor patch is the complete fix. Quell reduces exposure and proves your controls work in the meantime.

See how Quell handles emerging threats

FAQ

Is this an MPTCP bug?

No. The bug is in IPv4 TCP option handling, and the kernel.org record never mentions MPTCP. The Go Security Team says "the underlying bug is not specific to MPTCP" and that systems with no MPTCP listeners may be vulnerable to similar attacks. MPTCP matters because it is the configuration where a working exploit is claimed.

If I disable MPTCP, am I safe?

No. Disabling MPTCP closes the claimed exploit path, but an unpatched kernel with any IPv4 TCP listener still has the bug. Patch the kernel.

Are IPv6-only services affected?

Not by this CVE. The kernel.org record says IPv6 copies the options, so it isn't affected by the main issue. A related IPv6 migration issue, set only by CALIPSO, gets a separate patch.

Is CVE-2026-98432 being exploited?

No exploitation has been reported, and it is not on CISA KEV as of November 1, 2026. Public code triggers or detects the bug but does not take over a host.

Is RHEL fixed?

Not yet. Red Hat lists RHEL 8, 9 and 10 as affected with no fixed kernel, and its bulletin RHSB-2026-016 gives a packet-filter mitigation while it expedites fixes. Red Hat also documents MPTCP as disabled by default on RHEL, which closes the claimed exploit path but not the bug.

Updates

Nov 1, 2026. First published. Public trigger code since Oct 30; no exploitation reported; not on CISA KEV.

Sources

We publish an advisory when a vulnerability is Critical or on CISA KEV, has one identifiable component to check, and has a public proof of concept or reported exploitation. Advisories are updated as exploitation status changes.