threat alerts

Linux Kernel – IPv4 TCP use-after-free remote code execution (CVE-2026-98432)

A race condition in the Linux kernel’s IPv4 TCP connection handling (CVE-2026-98432) lets a remote, unauthenticated attacker trigger a use-after-free on any exposed TCP service. A public proof of concept already reaches root code execution against MPTCP listeners. Here’s which kernels are affected, where fixes have shipped, and what to do until you can patch.

Vulnerability

A race condition in the Linux kernel’s IPv4 TCP connection-setup code lets a remote, unauthenticated attacker who can reach any exposed TCP service trigger a use-after-free on the socket’s IP options structure.

The bug sits in Linux’s IPv4 TCP connection-handling code. It has existed since commit 079096f103fa, which changed how pending connection requests are stored.

When Linux creates a child socket for a new connection, it transfers the pending request’s IP options to that socket without copying them. At the same time, another CPU may still be processing a retransmitted SYN for the same request, and reading those options to send a SYN-ACK.

The reading CPU uses RCU (Read-Copy-Update). When the child socket is destroyed, its IP options are freed immediately with kfree(). That can leave the other CPU reading memory that has already been freed.

A related version of the bug affects request-socket migration, enabled through the tcp_migrate_req setting or an appropriate BPF reuseport program. During migration, the original request socket and its clone share the same IP-options memory. The request-socket destructor can free that memory while it’s still being read.

The upstream fix changes both affected cleanup paths to use kfree_rcu(), which delays freeing the memory until existing RCU readers have finished.

Affected files: net/ipv4/af_inet.c and net/ipv4/tcp_ipv4.c.

IPv6 isn’t affected by the primary bug, because the IPv6 handshake path copies IP options. A related IPv6 CALIPSO migration issue in tcp_v6_reqsk_destructor() is being addressed in a separate patch.

CVE and severity

The vulnerability is tracked as CVE-2026-98432.

The Linux kernel CNA rates it CVSS v3.1 9.8 (Critical). The CNA’s score is based on an attacker triggering the race with IPv4 SYN packets that carry Record Route or Timestamp IP options, then exploiting the resulting memory corruption.

Downstream vendors score it between 5.9 and 8.1, because of differing attack-complexity assumptions. Distribution vendors consider the race difficult to win reliably.

The fix was committed upstream on October 5, 2026. The CVE was published 10 days later.

Impact

Successful exploitation can:

  • leak adjacent kernel memory, including addresses that defeat Kernel Address Space Layout Randomization (KASLR)
  • corrupt kernel memory
  • crash the host
  • overwrite a kernel callback pointer and execute an attacker-chosen command as root

Exploit status

No in-the-wild exploitation is known, and the CVE isn’t in the CISA Known Exploited Vulnerabilities (KEV) catalog.

A working exploitation technique is publicly described. The public proof of concept, generated with Anthropic’s Claude, chains two effects. It first leaks a kernel address to bypass KASLR. It then uses an overwrite primitive to redirect a kernel callback to attacker-controlled payload memory, achieving code execution as root.

The published proof of concept specifically targets servers with a listening Multipath TCP (MPTCP) endpoint. Exploitability against ordinary TCP listeners hasn’t been established. The Go security team notes that the underlying bug isn’t specific to MPTCP.

The reported exploit took about 48 minutes to leak a kernel address, and another five minutes to achieve command execution.

Affected component and versions

The flaw has been in the kernel since 4.4. It affects every maintained stable branch before these fixed releases: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and the 7.3 mainline.

Distribution status as of October 30, 2026:

  • Fixed packages shipped for at least some kernels: Debian, Oracle Linux, SUSE and Amazon Linux.
  • No fix released yet: Ubuntu, including cloud, FIPS and real-time kernels, some marked work in progress; Red Hat, with RHEL 8, 9 and 10 marked Affected; and OpenShift 4, marked Affected.

Fixed status varies by product line and kernel flavor.

Fix and mitigation

The authoritative fix is the kernel upgrade.

  • Install your distribution’s fixed kernel package as soon as it’s available, and reboot.
  • If you build and run a mainline kernel directly, upgrade to one of these stable releases or later: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 or 7.3 (mainline).
  • Where a distribution has shipped fixes (Debian, Oracle Linux, SUSE and Amazon Linux), check the vendor advisory for the exact package version.
  • Rebuild and redeploy any container host, cloud image, hypervisor or appliance that pins a vulnerable kernel.
  • Container userspace isn’t affected, but every host whose kernel services untrusted TCP traffic must be patched.

No vendor has published a mitigation that fully substitutes for patching. These controls reduce exposure only:

  • Restrict exposure of TCP listeners to untrusted networks with host firewalls, cloud security groups or network segmentation. The bug requires the attacker to reach a listening TCP socket and send IPv4 SYNs carrying IP options.
  • Drop ingress IPv4 packets carrying Record Route (option 7) or Timestamp (option 68) IP options at the perimeter. These options are extremely rare in modern traffic. Blocking them removes the trigger documented in the Linux CNA’s scoring.
  • Disable MPTCP listeners where they aren’t required. The Go security team describes this as a fragile mitigation: a single exposed MPTCP listener reopens the published exploit path, and the underlying bug isn’t MPTCP-specific. It does remove the only publicly described root remote code execution primitive. On systems that support it: sysctl -w net.mptcp.enabled=0
  • Disable TCP request-socket migration where it isn’t in use, which covers the second use-after-free variant: sysctl -w net.ipv4.tcp_migrate_req=0
  • Prefer IPv6 for any service you can. The primary IPv4 bug isn’t reachable over IPv6, because the IPv6 handshake duplicates the options.

References

Tags

Related Posts