A critical vulnerability in the Linux kernel's IPv4 TCP stack — tracked as CVE-2026-98432 (CVSS 3.1 9.8 per the kernel CNA) — was published on 15 October 2026, and on 27 October researchers demonstrated a lab exploit chain that reaches unauthenticated remote root on vulnerable servers. That sounds like patch-everything-now territory, and mostly it is. But the details matter: the RCE is proven in a lab against a specific configuration, no exploit is public, and the vendor scoring ranges from 9.8 Critical down to Red Hat's 5.9 Moderate. This post walks through what the bug is, what was actually demonstrated, and what a defender should do this week.
To be clear about provenance: IKZERO did not discover this vulnerability and played no part in the disclosure. This is our technical read of the BeaconLab CSIRT alert, the kernel fix commit, and the researchers' writeup (published via Anthropic's report on AI-assisted vulnerability discovery), written for the teams who run Linux servers and need to decide what to do about it.
The bug: IP options freed without an RCU grace period
TCP handshakes don't start with a full socket. The kernel creates a lightweight request socket (reqsk) to hold half-open connection state, including the IP options from the connection request — the inet_opt structure attached to the child socket, and ireq_opt stashed on the request socket itself.
The defect is a textbook temporal-safety failure: those IP option structures are freed without waiting for an RCU grace period. RCU is the kernel's reader-writer synchronization primitive; freeing shared data without letting in-flight readers finish is exactly the pattern RCU exists to prevent. Two windows open:
- Retransmitted SYN vs. child teardown. If one CPU processes a retransmitted SYN for a connection at the same moment another CPU is destroying that connection's child socket, the retransmit path dereferences the already-freed options inside
ip_options_build(). - Request socket migration. The same class of bug exists when request sockets are migrated between listening sockets — active when
net.ipv4.tcp_migrate_req=1or aBPF_SK_REUSEPORT_SELECT_OR_MIGRATEprogram is loaded.
Scope notes: IPv4 only for the primary issue (IPv6 is unaffected; its analogous case exists only with CALIPSO and is being patched separately). The defect was introduced by commit 079096f103fa and fixed by e3f33b0a1d89 (7.3-rc7), backported to every stable branch. Debian shipped it in DSA-6568; Oracle's UEK errata landed the day after publication.
The exploit chain: 48 minutes to a leak, 5 minutes to root
The researchers' demonstration works against a Linux server running an MPTCP (Multipath TCP) listener — meaning an application explicitly created an MPTCP socket. The chain has two stages:
| Stage | Time | Outcome |
|---|---|---|
| Kernel pointer leak | ~48 minutes | Defeat KASLR by racing the UAF repeatedly |
| Control-flow hijack → root shell | ~5 minutes | Arbitrary execution as root, no credentials, no interaction |
Three properties make this chain practical despite a nanosecond-scale race window:
- Failure is free. A lost race causes only a failed TCP handshake — no crash, no oops, nothing a monitoring stack would flag. The attacker retries indefinitely. That converts a tiny per-attempt success rate into a bounded wait.
- MPTCP keeps the primitive reachable across repeated handshake events, giving the UAF a repeatable trigger.
- Leak-then-hijack is the standard kernel RCE pattern: first turn "read freed memory" into a pointer disclosure, then turn stale-structure access into control flow.
The caveats that matter
The CVE record itself describes only the IPv4 TCP UAF. The MPTCP linkage and the root outcome come solely from the researchers' report. Concretely:
- Whether RCE is possible without MPTCP is unconfirmed. The safe operating assumption: unpatched internet-facing Linux is remotely crashable, and unpatched hosts with MPTCP listeners are remotely rootable.
net.mptcp.enabled=1— the kernel default — does not mean you're exposed. A listener exists only where an application explicitly creates an MPTCP socket. Which distro services do that by default is still an open question.- No exploit code has been published. The bug is not in CISA's Known Exploited Vulnerabilities catalog, and no in-the-wild exploitation is known.
Why the scores disagree: 9.8 vs 5.9
| Source | Score | Position |
|---|---|---|
| Kernel CNA | CVSS 3.1 9.8 Critical | Network vector, low complexity, no privileges or interaction |
| Ubuntu | 9.8 (CVSS 4.0: 8.3), highest priority | Treats the upstream assessment as authoritative |
| SUSE | 8.1 (CVSS 4.0: 9.2) | High attack complexity |
| Oracle | 8.1 (preliminary) | High complexity |
| Red Hat | 5.9 Moderate | High complexity; worst practical outcome is a kernel crash / DoS |
Both camps have a point. The bug is remotely triggerable without authentication — that's the 9.8 vector math. But reliably winning a CPU race from across the internet is real complexity, and the guaranteed outcome of a single hit is a crash. The lab RCE breaks the tie: given an MPTCP listener and unlimited retries, it can be root. Our read for defenders: patch like it's 9.8, scope like it's 5.9 — and prioritize MPTCP hosts inside that scope.
Patch matrix
| Platform | Status (at alert date) |
|---|---|
| Upstream stable | Fixed — 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 |
| Debian 12 (bookworm) | Fixed — 6.1.190-1, plus linux-6.12 6.12.113-1~deb12u1 (DSA-6568) |
| Debian 13 (trixie) | Fixed — 6.12.113-1 |
| Oracle Linux (UEK) | Fixed — ELSA-2026-500397/98/99, published 16 Oct 2026 |
| SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Fixed — 6.12.0-160000.40.1 |
| SLES 15 SP4–SP7, SLES 16.0, SLE Micro 5.x | Fix in progress |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | Fix in progress — no kernel yet |
| Ubuntu 20.04 / 18.04 / 16.04 | No fixed kernel available |
| RHEL 8 / 9 / 10 (+ RT, In-Vehicle OS, OpenShift RHCOS) | Fix deferred; vendor states no mitigation is available |
Not affected: Ubuntu 14.04, RHEL 7, SLES 11 SP4. Appliances and unlisted distributions: check with the vendor directly.
What to do this week
1. Inventory — find your exposure before you patch. Prioritize internet-facing systems, then anything running an MPTCP listener:
# Kernel-level MPTCP switch (default 1 — this alone is NOT exposure)
sysctl net.mptcp.enabled
# The second race window's trigger
sysctl net.ipv4.tcp_migrate_req
# MPTCP sockets/endpoints and regular listeners, cross-reference app configs
ss -M
ss -tlnp
# eBPF reuseport programs that can select-or-migrate
bpftool prog list | grep -i reuseport
Audit application configs for MPTCP usage (IPPROTO_MPTCP, mptcp socket calls, mptcpd) — the RCE path requires an application-created MPTCP socket.
2. Patch and reboot. This is the only confirmed remediation; no vendor has endorsed a mitigation. Install your distribution's fixed kernel and reboot (or live-patch where your vendor's livepatch coverage includes this CVE).
3. Optional attack-surface reduction — with clear expectations. Where MPTCP is genuinely unused:
sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" >> /etc/sysctl.d/99-mptcp-disable.conf
This removes the demonstrated RCE path but does not fix the underlying UAF — the remote crash primitive remains. No vendor endorses it as a mitigation for the CVE, so test before fleet-wide rollout.
4. Detect. The exploit is quiet by design — failed races produce failed handshakes. Watch for:
- Elevated rates of incomplete or retransmitted SYNs from single sources against TCP services
- Slab corruption messages,
ip_options_buildwarnings, or TCP stack oopses indmesg/journal - Repeated handshake failures correlated by source IP — the 48-minute leak phase implies many attempts
- MPTCP socket activity where none is expected
5. Track. If this lands in CISA's KEV catalog, re-triage immediately. Ubuntu and Red Hat are the two largest unresolved vendor gaps — watch their advisories.
What this means for your stack
The scoring dispute is not noise; it's a live lesson in how kernel bugs get risk-assessed. The guaranteed impact (crash) and the demonstrated impact (lab root under specific conditions) sit far apart, and vendor telemetry can't yet tell you which one your servers would meet. That ambiguity is exactly the situation where defensive patching discipline earns its keep: inventory, patch, reboot, verify — in that order, with the highest-exposure hosts first.
Remote race conditions in core network stacks are the class of flaw we hunt for in a penetration test, the patching and detection discipline above is what we operationalize through DevSecOps pipeline integration, and the exposure triage — which of your servers run MPTCP, which of your appliances are affected — is a conversation we run through security consultancy. If your patch matrix has a "deferred" row in it, talk to us and we'll help you decide what to do while you wait.
Frequently Asked Questions
Is CVE-2026-98432 remote code execution against Linux?
Yes in the lab, with conditions. Researchers demonstrated unauthenticated remote root against a vulnerable Linux server running an MPTCP listener — roughly 48 minutes to leak a kernel pointer and 5 more to a root shell. The CVE record itself proves only a use-after-free with a minimum impact of remote denial of service; RCE without MPTCP is unconfirmed, no exploit is public, and no in-the-wild exploitation is known.
Do I need MPTCP enabled to be vulnerable?
No — but MPTCP changes your worst case. The underlying UAF in the IPv4 TCP stack exists regardless and gives a remote attacker at minimum a crash/DoS primitive. The demonstrated root-level RCE requires an application-created MPTCP listener. Note that net.mptcp.enabled=1 (the kernel default) alone does not create a listener.
Which kernel versions fix CVE-2026-98432?
Upstream stable: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3. Debian 12 and 13 have fixed kernels (6.1.190-1 and 6.12.113-1), Oracle Linux UEK errata shipped 16 October, and SUSE Linux Micro 6.2 / openSUSE Leap 16.0 are fixed. Ubuntu and SUSE enterprise products were still in progress at alert time, and Red Hat deferred its fix.
Does sysctl net.mptcp.enabled=0 fully mitigate it?
No. It removes the demonstrated RCE path by preventing MPTCP sockets, but the underlying IPv4 TCP use-after-free — the crash primitive — remains until you install a fixed kernel and reboot. No vendor endorses the sysctl as a mitigation for the CVE, so test it before applying fleet-wide.
Why does Red Hat score this 5.9 while the kernel CNA says 9.8?
They are weighing different things. The 9.8 vector reflects a remotely triggerable, unauthenticated network bug. Red Hat weights the high attack complexity of winning a CPU race remotely and judges the most practical outcome to be a kernel crash, not code execution. The lab RCE against MPTCP servers supports the higher reading for that specific configuration; until more is known, patch at the urgency of the higher score and scope exposure at the lower one.
Sources: BeaconLab CSIRT Alert 2026-130; kernel fix commit e3f33b0a1d89; Anthropic, "Discovering Vulnerabilities with Claude" (27 Oct 2026); NVD; Debian DSA-6568; distribution CVE trackers. Exploit code has not been publicly released.
