Low Severity CVE-2026-98432
Published: Nov 2, 2026

[GitHub] tcp2kaslr

Other
Type
N/A
CVSS Score
1
Views
Anonymous
Author

Description

CVE-2026-98432: a plain IPv4 TCP server is vulnerable, MPTCP is not the trigger. Bug trigger, evidence and analysis.

# CVE-2026-98432

_Written by DeepSeek._

**A plain IPv4 TCP server is vulnerable. MPTCP is not the trigger.**

We built Linux 6.18.55 from the release tarball and made the kernel read freed
memory on a normal `IPPROTO_TCP` listener. KASAN reported it twice. No MPTCP
socket was ever created, and one run had MPTCP switched off in the kernel.

The same bug makes the kernel copy bytes out of a freed object into the reply it
sends back. That is the primitive a KASLR break needs, and we have observed it
happen in unpublished work. We did **not** build a kernel-address leak, and we
did **not** prove a write.

What is proven here, with code and logs: the use-after-free is real, stock TCP
reaches it, and the upstream fix stops it.

## The runs

| Kernel | MPTCP | Attempts | Time | Result |
|---|---|---:|---:|---|
| 6.18.55, no fix | not used | 134,955 | 34 s | **KASAN use-after-free** |
| 6.18.55, no fix | switched off | 191,431 | 80 s | **KASAN use-after-free** |
| 6.18.55 + fix | not used | 439,316 | 411 s | clean |

## How hard is it to hit?

Very hard. With KASAN the reader is slow, so the bug shows up within a few
hundred thousand attempts. On a normal kernel it is far rarer: across about
**48 million attempts we saw two events, both inside the same five seconds**.

That is too few to state a rate. The most we will claim is a bound of roughly
`1e-7` per attempt, and even that is a best case, because our harness forces the
two packets onto two CPUs and a real NIC usually sends one flow to one CPU.

So a clean run does **not** mean a safe kernel. Read `ANALYSIS.md` sections 5.2
and 6 before quoting any number.

## The bug in plain words

A TCP server gets a SYN. The SYN carries an IPv4 option (Record Route or
Timestamp). The kernel saves those options on the request socket.

A second SYN for the same connection arrives. The kernel builds a SYNACK for it
and reads the saved options.

At the same time the handshake finishes. The child socket gets **the same
pointer**, not

Community Rating
0

Login to rate this exploit

Quick Actions