Introduction
A race condition in the code that sets up new IPv4 TCP connections in the Linux kernel, tracked as CVE-2026-98432, lets a remote attacker with no credentials make the kernel read memory it has already freed. The kernel CVE team rates it 9.8 on the CVSS scale. SUSE rates it 8.1 and, on 29/10/2026, published nine security advisories with fixed kernels for most of its supported releases ⚠️. The bug was introduced in Linux 4.4, so almost every kernel in use today carries it until it is updated.
Technical Context: How the Race Works
The flaw sits in the TCP three-way handshake 🔓:
- Ownership without a copy: when a connection completes, tcp_v4_syn_recv_sock() transfers the IP options stored with the pending request (ireq_opt) to the new child socket (inet_opt) without copying them.
- A second reader: another CPU can be processing a retransmitted SYN for the same request at the same moment, building a SYN-ACK in tcp_v4_send_synack(). That path reads the options under rcu_read_lock() only.
- The free: TCP child sockets do not use SOCK_RCU_FREE, and inet_sock_destruct() frees the options with a plain kfree(). If the child is destroyed while the SYN-ACK is still being built, ip_options_build() reads freed memory.
- A second path: request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF reuseport program that migrates requests) shares the same options between a request and its clone, and has the same problem.
- IPv6: not affected by the first path, because tcp_v6_syn_recv_sock() duplicates the options.
The upstream fix frees the options only after an RCU grace period, with kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(), as other paths that replace these options already did 🔧. It is in the stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, and in 7.3.
Why 9.8 and 8.1
The kernel CVE team and SUSE agree on every CVSS 3.1 metric except attack complexity. The kernel team rates it low, considering both sides of the race attacker-induced: a SYN carrying IPv4 Record Route or Timestamp options, then retransmitted to try to win the race. SUSE, Red Hat and Oracle rate it high because the race is hard to win. In CVSS 4.0, SUSE scores it 9.2 with the attack requirements marked as present.
Anthropic reported on 27/10/2026 that its AI model wrote a root exploit against servers with a Multipath TCP (MPTCP) listener. Leaking a kernel address past KASLR took 48 minutes and reaching command execution took 5 more, and a lost race only fails that connection attempt without crashing the host. The Go Security Team noted that Go 1.24 and later listen with MPTCP by default, and that the bug is not specific to MPTCP. No exploitation had been reported as of 29/10/2026.
SUSE Status on 31/10/2026 🐧
From the SUSE CVE page, which lists the fixed package for each product:
| Product | State | Fixed kernel-default |
|---|---|---|
| SLES 16.0, SLES for SAP Applications 16.0, SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Released | 6.12.0-160000.40.1 |
| SLES 15 SP6 LTSS, SLES for SAP Applications 15 SP6 | Released | 6.4.0-150600.23.143.1 |
| SLES 15 SP5 LTSS, SLES for SAP Applications 15 SP5, SLE Micro 5.5 | Released | 5.14.21-150500.55.195.1 |
| SLES 15 SP4 LTSS, SLES for SAP Applications 15 SP4, SLE Micro 5.3 and 5.4 | Released | 5.14.21-150400.24.246.1 |
| SLES 15 SP7, SLED 15 SP7, SLES for SAP Applications 15 SP7 | In progress | not yet released |
| SLES 12 SP5 LTSS, SUSE Linux Micro 6.0 and 6.1 | Affected | not yet released |
The SLE Micro 5.3 real-time kernel was still pending on the same date.
Practical Implications: What to Do on SUSE
- Check: zypper list-patches --cve=CVE-2026-98432 shows whether the update is available for the installed product.
- Install: zypper patch --cve=CVE-2026-98432 installs it.
- Reboot: the new kernel only takes effect after a reboot into it; rpm -q kernel-default and uname -r confirm the version in use.
- Find exposure: ss -Mtln lists the MPTCP listeners on the host, the path of the published exploit.
- SLES 15 SP7: no fixed kernel yet. No vendor lists a mitigation, and disabling MPTCP per program only narrows the known exploit path.
Strategic Conclusion
Update the kernel on every SUSE release that already has the fix, and reboot: it is the only measure that closes the race, because the bug is in the TCP handshake itself and not in an optional feature. For SLES 15 SP7, follow the SUSE CVE page and the Bugzilla entry until the kernel is released, and schedule the reboot window now.
Track the fix:
- SUSE CVE page for CVE-2026-98432
- SUSE Bugzilla bsc#1285685
- SUSE-SU-2026:4937-1, advisory for SLES 15 SP4 LTSS
Original report by Swati Khandelwal published on The Hacker News on 29/10/2026, updated on 30/10/2026. SUSE status checked on the SUSE CVE page on 31/10/2026.
