CVE-2026-98432: Linux Kernel IPv4 TCP Use-After-Free Root Cause, Detection and Mitigation

CVE-2026-98432 is a remote, unauthenticated use-after-free vulnerability in the Linux kernel IPv4 TCP handshake mechanism, present in every kernel from 4.4 up to the fixed stable releases. A remote, unauthenticated attacker transmits a TCP SYN packet that carries IPv4 Record Route or Timestamp options to any listening IPv4 TCP port, then sends a retransmitted SYN flag against the connection being completed and torn down. The kernel then builds a SYN-ACK from freed option memory in ip_options_build().

CVE-2026-98432 at a glance

Field	Value
CVE	CVE-2026-98432
Component	net/ipv4/af_inet.c, net/ipv4/tcp_ipv4.c
Type / CWE	Use-after-free caused by a race between concurrent CPUs. Neither the kernel CNA nor NVD assigns a CWE (NVD’s Weakness Enumeration table is empty and NVD has not scored it), and Red Hat’s CWE data was unavailable on 2026-11-01. CWE-416 (Use After Free) with CWE-362 (Race Condition) fits the description
CVSS v3.1 (kernel CNA)	9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0	No CNA v4 score. SUSE: 9.2, AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Ubuntu: 8.3, AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
Precondition	A listening IPv4 TCP socket reachable by the attacker, and IPv4 packets with options reaching the host. No authentication and no user interaction
Exploited in the wild	No public reports and not in CISA KEV catalogVersion 2026.10.30 (dateReleased 2026-10-30T17:02:45Z). Anthropic reports a private, working remote root exploit against an MPTCP listener and names CVE-2026-98432 in its post.
Reported by	Xinyang Ge (Anthropic), per the Reported-by: tag in the fix commit
Introduced	Commit 079096f103fa (“tcp/dccp: install syn_recv requests into ehash table”), Linux 4.4, for the main path. Commit c905dee62232 (“tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.”) for the migration path. Both are Fixes: tags on the fix commit
Fixed upstream	Commit e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”), authored by Eric Dumazet 2026-10-01, committed by Jakub Kicinski 2026-10-05, reviewed by Kuniyuki Iwashima, in 7.3-rc7
Fixed stable	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
Vendor workaround	Drop inbound IPv4 TCP packets with IP options (Red Hat RHSB-2026-016, AWS, AlmaLinux). Disabling MPTCP reduces exposure to the demonstrated chain only; it does not fix the bug

CVE-2026-98432 root cause

This section has been built from the fix commit e3f33b0a1d89 on git.kernel.org: the commit message and the diff. When a SYN arrives with IPv4 options, ip_rcv_options() and tcp_v4_save_options() store them in the request socket as ireq->ireq_opt (a struct ip_options_rcu) so the kernel can echo them in the SYN-ACK.

1. The handshake completes. tcp_v4_syn_recv_sock() hands ireq->ireq_opt to the child socket as newinet->inet_opt without copying it.
2. At the same time, another CPU handles a retransmitted SYN for the same request socket and sends a SYN-ACK through tcp_check_req() and tcp_v4_send_synack(). That code and inet_csk_route_req() read the options under rcu_read_lock() only. ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice.
3. Since 079096f103fa, request sockets are processed without the listener lock. Hence, nothing stops the child socket from being closed and freed during step 2. These TCP child sockets lack SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree().
4. The SYN-ACK is built from this freed memory. If the attacker reclaims that slab object, a stale optlen copies adjacent heap bytes into the reply (leak), stale srr/rr/ts offsets steer writes (corruption), and an oversized optlen can make skb_push() overrun the headroom and call skb_under_panic() causing a crash.

The second path is request socket migration (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program, both off by default). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so old and new share ireq_opt. reqsk_migrate_reset() clears the old pointer, but another CPU can still be using the options when tcp_v4_reqsk_destructor() frees them with plain kfree().

The fix is a code that is only two lines long!

--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -161,7 +161,7 @@ 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
@@ -1209,7 +1209,7 @@ static int tcp_v4_send_synack(const struct sock *sk, struct dst_entry *dst,
 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);
 }

• The fix changes only the free side. ip_options_build() still reads optlen twice; that is now safe only because the memory outlives the RCU grace period.
• The rcu argument names the rcu_head that struct ip_options_rcu already has. No struct layout changed, so backports and livepatches are simple.
• Other writers of inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()) already used kfree_rcu().

The af_inet.c hunk context includes psp_sk_assoc_free(sk), which exists only in recent mainline. Vendor backports will look different around the same line. To confirm a vendor kernel is patched, check its source package for kfree_rcu on inet->inet_opt in inet_sock_destruct(), not the version string alone.

Now for the good news – in my analysis IPv6 does not seem to be affected as tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration bug for ipv6_opt, which only Common Architecture Label IPv6 Security Option protocol (CALIPSO) sets, and the kernel says that fix comes in a separate patch. A kernel patched for CVE-2026-98432 still carries that IPv6 variant.

Variant analysis:

As I see it, three patterns in this bug are worth hunting for in the networking stack. None of these is a claim that another bug exists, but they are where I would look first:

• RCU readers, non-RCU free: The readers already used rcu_read_lock(); only the free side was wrong. Any object read under RCU but released with plain kfree() in a destructor is a candidate. Other writers of inet_opt had already been converted to kfree_rcu(), so the inconsistency itself was the signal.
• Unchecked ownership transfer: tcp_v4_syn_recv_sock() moves the pointer to the child while the request socket can still be used. IPv6 avoided the bug because tcp_v6_syn_recv_sock() duplicates the options [Certain]. Compare other IPv4 and IPv6 twin paths for the same asymmetry.
• Length fields read twice: ip_build_and_send_pkt() and ip_options_build() read opt->optlen twice [Certain]. The fix keeps the memory alive but does not snapshot the length. Double reads of a length from shared memory are worth flagging even when the lifetime is now correct.

Fixed builds for CVE-2026-98432 by distribution

Distribution	Status and fixed build (as of 2026-11-01)
Upstream stable	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
RHEL 10 / 10.2 EUS	RHSA-2026:93413: kernel-6.12.0-211.72.1.el10_2, including kernel-rt for x86_64 and aarch64
RHEL 9 / 9.8 EUS, SAP	RHSA-2026:93412: kernel-5.14.0-687.64.1.el9_8, including kernel-rt for x86_64 and aarch64
RHEL 8 / 8.10 ELS	RHSA-2026:93414: kernel-4.18.0-553.182.1.el8_10
RHEL 8 Real Time / NFV	RHSA-2026:93415: kernel-rt-4.18.0-553.182.1.rt7.523.el8_10
Other Red Hat	Affected: OpenShift 4 and 5 RHEL CoreOS, RHEL for NVIDIA 26, older EUS minor streams. RHEL 6 and 7 not affected
AlmaLinux 8 / 9 / 10	Testing repository only: 4.18.0-553.180.2.el8_10, 5.14.0-687.61.2.el9_8, 6.12.0-211.69.2.el10_2
Debian 12 bookworm	linux 6.1.190-1 (DLA-4841-1); linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)
Debian 13 trixie	linux 6.12.113-1 (DSA-6568-1)
Ubuntu 22.04 to 26.10	Vulnerable, fixes in progress: 26.10 7.3.0-10.10, 26.04 7.0.0-43.43, 24.04 6.8.0-149.149, 22.04 5.15.0-203.213
Ubuntu 16.04 to 20.04	Vulnerable, no fix in progress for the main linux package
Ubuntu 14.04	Main linux not affected; linux-aws and linux-azure listed as vulnerable
SUSE	SLES 16.0 6.12.0-160000.40.1; SLES 15 SP6-LTSS 6.4.0-150600.23.143.1; SP5-LTSS 5.14.21-150500.55.195.1; SP4-LTSS 5.14.21-150400.24.246.1; SLES 15 SP7 in progress
Oracle Linux UEK	ELSA-2026-500397, -500398, -500399, 2026-10-16
Amazon Linux	AL2 ALAS2-2026-4065 plus 5.4/5.10/5.15 extras; AL2023 ALAS2023-2026-3365, kernel6.12 ALAS2023-2026-3335, kernel6.18 ALAS2023-2026-3251

Detecting CVE-2026-98432

The Anthropic post mentions the request-level detail. The trigger is a TCP SYN with IPv4 Record Route (option 7) or Timestamp (option 68), followed by retransmitted SYNs for the same connection. While the Anthropic’s leak stage ran for 48 minutes, meaning a real exploitation attempt will be a long burst of option-bearing SYNs from one source. Legitimate traffic rarely carries IPv4 options.

Anthropic's proof of concept took 53 minutes

• Stage 1, KASLR leak: 48Repeated SYNs with IPv4 options from one source
• Stage 2, control-flow hijack to root: 5Same bug, ends in a root shell command

Minutes per stage in Anthropic's test. The leak stage is the detection window.

Detection engineering notes

• Telemetry you need: The trigger lives in the IPv4 header, so you need packet-level visibility something like a network sensor, packet mirroring, or the host firewall log rule below. NetFlow and cloud flow logs record addresses and ports, not IP options, so they cannot see it.
• Sensor placement: Place the sensor where it sees traffic before a load balancer or proxy terminates TCP. A proxy that terminates the connection opens a new one to the backend, which protects that backend from the client’s options; a Layer 4 pass-through does not. AWS lists NLB TCP listeners as affected paths for that reason.
• False-positive sources: TCP SYNs carrying IP options are rare on modern networks. Expected sources: CIPSO (IP option (Type 134)) or NetLabel labeled networks, and scanners that set options on purpose, such as Nmap with --ip-options. Baseline as always before alerting at high severity.
• What a real attempt will look like: These will come from one source with many option-bearing SYNs to the same listener, retransmitted SYNs for the same connection, and failed handshakes, sustained for tens of minutes. That is why the third Suricata rule thresholds on volume from one source.
• Correlate host and network: High confidence comes from joining a network hit with a kernel log hit (skb_under_panic, ip_options_build) or an unexpected kernel-thread child process on the same host.
• MITRE ATT&CK mapping: T1190 Exploit Public-Facing Application for internet-facing listeners, and T1210 Exploitation of Remote Services for internal movement.

Detections using tcpdump, Suricata:

tcpdump

tcpdump -ni any '(ip[0] & 0x0f) > 5 and (tcp[tcpflags] & (tcp-syn|tcp-ack)) == tcp-syn'

Suricata

alert tcp any any -> $HOME_NET any (msg:"CVE-2026-98432 candidate - TCP SYN with IPv4 Record Route option"; flags:S,12; ipopts:rr; classtype:attempted-admin; sid:9843201; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"CVE-2026-98432 candidate - TCP SYN with IPv4 Timestamp option"; flags:S,12; ipopts:ts; classtype:attempted-admin; sid:9843202; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"CVE-2026-98432 likely race attempt - repeated option-bearing SYNs"; flags:S,12; ipopts:any; detection_filter:track by_src, count 50, seconds 60; classtype:attempted-admin; sid:9843203; rev:1;)

Frequently asked questions

What is CVE-2026-98432, in plain terms?

A flaw in how Linux handles the very first packets of a network connection. An attacker on the network can send specially timed connection attempts and, with enough tries, take full control of the server. No password and no action by anyone inside the organization is needed.

How urgent is CVE-2026-98432 for my organization?

Treat it as an emergency for every Linux server that accepts connections from networks you do not fully trust, starting with internet-facing systems. Anthropic, which reported the flaw, described a working attack that took about 53 minutes. There is no public attack code and no public report of attacks so far. Do not plan around that lasting.

Is CVE-2026-98432 being exploited in the wild?

There is no public report of exploitation as of 2026-11-01, and it is not in the CISA Known Exploited Vulnerabilities catalog version 2026.10.30. A private working exploit exists, so that can change quickly.

Which of our systems are exposed to CVE-2026-98432?

Any Linux system on kernel 4.4 or later that accepts TCP connections over IPv4. That covers servers, virtual machines, container and Kubernetes hosts, and many appliances built on Linux. Windows systems are not affected. For appliances, ask each vendor whether their product is affected and when a fix ships.

Are our cloud workloads affected by CVE-2026-98432?

Servers and container nodes you manage yourself need patching by your team. AWS lists self-managed EC2, EKS nodes, ECS on EC2, Fargate and Bottlerocket among affected services and says Lambda is not affected. For managed services, check each provider’s bulletin for who patches what.

Will the temporary fix for CVE-2026-98432 disrupt the business?

The interim firewall rule drops network packets that carry a rarely used header feature, so ordinary web, application and database traffic is unaffected. It does break labeled networking used in some high-security environments. Test it on a few systems first, and treat it as a stopgap: it does not replace the patch.

Do we need to reboot to fix CVE-2026-98432?

Yes. A kernel update only takes effect after a reboot, unless your team uses live patching. Plan maintenance windows now, internet-facing systems first.

How do we know remediation of CVE-2026-98432 is complete?

Ask for evidence that every exposed system is running a fixed kernel or a live patch, not only that the update is installed. Scanner results for this CVE can flag patched systems as vulnerable because of how the version data was published, so the running kernel version is the proof.

If our scans are clean, does that mean we were not attacked?

No. This attack leaves little on disk. The evidence sits in network captures and kernel logs, which a reboot can wipe. For critical internet-facing systems, have the team save that evidence before patching.

What should I ask my security team this week?

Five things: a list of internet-facing Linux systems; patch status by Linux distribution, with Ubuntu and older Red Hat minor releases called out because they have no fix yet; where the interim firewall rule is deployed; whether the detections in this post are running; and which appliance vendors have been asked for a fix date.

Which Linux kernel versions are affected by CVE-2026-98432?

Linux 4.4 and later, until 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 or 7.3. Kernels 4.4 to 5.4 need a vendor backport.

Does disabling MPTCP fix CVE-2026-98432?

No. The bug is in plain IPv4 TCP code. Disabling MPTCP only removes the configuration Anthropic used in its demonstrated exploit.

Is IPv6 affected by CVE-2026-98432?

Not by the main path. A separate IPv6 issue in the migration path, reachable only with CALIPSO, is still open.

How do I detect CVE-2026-98432 exploitation attempts?

Alert on TCP SYN packets with IPv4 options (header length over 20 bytes), especially sustained bursts from one source, and correlate with kernel log entries for skb_under_panic or ip_options_build. Flow logs cannot see IP options; you need packet-level telemetry.