CVE-2026-98432

Geschrieben von DeepSeek.

Ein einfacher IPv4-TCP-Server ist anfällig. MPTCP ist nicht der Auslöser.

Wir haben Linux 6.18.55 aus dem Release-Tarball gebaut und den Kernel dazu gebracht, auf einem normalen IPPROTO_TCP-Listener freigegebenen Speicher zu lesen. KASAN hat es zweimal gemeldet. Es wurde nie ein MPTCP-Socket erstellt, und in einem Lauf war MPTCP im Kernel deaktiviert.

Derselbe Fehler bringt den Kernel dazu, Bytes aus einem freigegebenen Objekt in die zurückgesendete Antwort zu kopieren. Das ist die Primitive, die ein KASLR-Break benötigt, und wir haben beobachtet, dass dies in unveröffentlichter Arbeit geschieht. Wir haben keinen Kernel-Adress-Leak gebaut und keinen Write nachgewiesen.

Was hier mit Code und Logs bewiesen wird: Der Use-after-Free ist real, Standard-TCP erreicht ihn, und der Upstream-Fix stoppt ihn.

Die Läufe

Kernel	MPTCP	Versuche	Zeit	Ergebnis
6.18.55, ohne Fix	nicht verwendet	134.955	34 s	KASAN use-after-free
6.18.55, ohne Fix	deaktiviert	191.431	80 s	KASAN use-after-free
6.18.55 + Fix	nicht verwendet	439.316	411 s	sauber

Wie schwer ist es zu treffen?

Sehr schwer. Mit KASAN ist der Reader langsam, sodass der Fehler innerhalb einiger hunderttausend Versuche auftritt. Auf einem normalen Kernel ist er weit seltener: Bei etwa 48 Millionen Versuchen sahen wir zwei Ereignisse, beide innerhalb derselben fünf Sekunden.

Das ist zu wenig, um eine Rate anzugeben. Das Höchste, was wir behaupten, ist eine Obergrenze von ungefähr 1e-7 pro Versuch, und selbst das ist ein Best-Case, weil unser Harness die beiden Pakete auf zwei CPUs zwingt und eine echte NIC normalerweise einen Flow an eine CPU sendet.

Ein sauberer Lauf bedeutet also nicht einen sicheren Kernel. Lies die Abschnitte 5.2 und 6 in ANALYSIS.md, bevor du irgendeine Zahl zitierst.

Der Fehler in einfachen Worten

Ein TCP-Server erhält ein SYN. Das SYN trägt eine IPv4-Option (Record Route oder Timestamp). Der Kernel speichert diese Optionen am Request-Socket.

Ein zweites SYN für dieselbe Verbindung trifft ein. Der Kernel baut dafür ein SYNACK und liest die gespeicherten Optionen.

Gleichzeitig schließt der Handshake ab. Der Child-Socket erhält denselben Zeiger, keine Kopie. Der Server schließt das Child, und der Kernel gibt die Optionen mit einem einfachen kfree() frei.

Der SYNACK-Code liest diesen Speicher noch. Das ist der Use-after-Free. Derselbe Lesevorgang ist es, der freigegebene Bytes in das Paket bringt.

Was dieses Repo nicht ist

Es ist ein Bug-Trigger, kein Exploit. Es leakt keine Kernel-Adressen, schreibt keinen Kernel-Speicher und erlangt kein Root. Es zeigt den Kernel beim Lesen freigegebenen Speichers; KASAN ist der Richter.

Das Repo endet hier absichtlich. Spätere Stufen wurden privat bearbeitet und werden hier nicht veröffentlicht.

Reproduzieren

scripts/get-kernel.sh              # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln       # KASAN kernel, no fix
scripts/build-kernel.sh patched    # KASAN kernel, with the fix
scripts/build-harness.sh           # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest    # checks the wiring only
scripts/run.sh vuln 600            # expect a KASAN report
scripts/run.sh patched 600         # expect nothing

Du benötigst gcc, make, bison, flex, bc und qemu-system-x86_64. KVM hilft sehr. Die VM benötigt 2 GB RAM und 8 vCPUs.

Ein einzelner Lauf zeigt möglicherweise nichts an. Das ist kein Beweis für einen sicheren Kernel. Führe ihn mehrere Male aus und lies die Einschränkungen in ANALYSIS.md.

Prüfe deinen eigenen Kernel

Vertraue nicht der Versionszeichenkette. Sieh dir den Code in der Binärdatei an.

scripts/check-free-sites.py

Es findet die beiden freien Stellen im laufenden Kernel und zeigt, welche Funktion sie aufrufen: kfree (fehlerhaft) oder kvfree_call_rcu (behoben).

Auf der Maschine, auf der dies geschrieben wurde (6.18.59_1), verwenden beide Stellen kvfree_call_rcu, dieser Kernel ist also behoben.

Wer ist betroffen

Ein Host ist betroffen, wenn alle drei Bedingungen zutreffen:

1. er lauscht auf IPv4 TCP, und
2. der Peer sendet ein SYN mit IP-Optionen, und
3. das Programm schließt den akzeptierten Socket bald.

Der Angreifer kontrolliert Punkt 2. Daher sind die meisten Internetserver betroffen, und „wir verwenden kein MPTCP“ hilft nicht.

Zwei Hinweise:

• accept_source_route=0 schützt Sie nicht. Es blockiert nur Source Routing, nicht Record Route oder Timestamp.
• Wenn Sie noch nicht patchen können, verwerfen Sie eingehende SYNs, die IP-Optionen tragen. Dann speichert der Kernel niemals Optionen für den Request-Socket. Patchen ist besser.

Dateien

Pfad	Was
ANALYSIS.md	der vollständige Bericht: Quellpfad, Methode, Ergebnisse, Grenzen
harness/	der Fehlerauslöser, der als /init in QEMU läuft
patches/	der Upstream-Fix, verwendet für den Kontroll-Build
scripts/	Hilfsskripte zum Abrufen, Bauen, Ausführen und Prüfen
evidence/	KASAN-Berichte, Ausführungsprotokolle, Build-Vergleich

Geltungsbereich

Nur Test-Kernel, und nur solche, die Ihnen gehören. Nichts hier sollte auf Systeme gerichtet werden, die Sie nicht kontrollieren.

Lizenz

MIT für unseren Code und Text. patches/ enthält einen Linux-Kernel-Commit und bleibt unter GPL-2.0. Siehe LICENSE.