Der Kernel schloss diese 9.8-Lücke am 5. Oktober. Ubuntu und RHEL haben weiterhin nichts zu installieren

Am 5. Oktober nahm der Linux-Kernel einen Patch an, der so klein ist, wie Kernel-Patches nur sein können: zwei Aufrufe von kfree() wurden zu kfree_rcu(), an zwei Stellen im IPv4-TCP-Code. Zehn Tage später vergab das Kernel-CVE-Team die Nummer CVE-2026-98432, am 24. Oktober folgte der Score 9.8. Debian hatte am 16. Oktober einen festen Kernel. Ubuntu und Red Hat haben bis heute keinen – und keine Terminaussage.

Das ist der eigentliche Befund dieser Woche, lauter als die Schlagzeile, die den Fall bekannt machte.

Was kaputt ist

Der Fehler sitzt in dem Code, der IPv4-TCP-Verbindungen annimmt – also in Code, den jeder Server mit einem offenen Port ausführt. Auslöser ist ein TCP-SYN mit IPv4-Optionen, konkret Record Route oder Timestamp. Solche Optionen verschickt normaler Verkehr praktisch nie, aber nichts hindert einen Client daran. Der Kernel legt sie mit der halbfertigen Verbindung in ireq_opt ab. Wenn der Handshake abgeschlossen wird, gibt tcp_v4_syn_recv_sock() die Optionen an den neuen Child-Socket weiter, ohne sie zu kopieren: Request-Socket und Child zeigen auf denselben Speicher. Schickt der Client sein SYN im richtigen Moment erneut, kann eine andere CPU dieses Retransmit aufgreifen und in ip_options_build() ein SYNACK aus denselben Optionen bauen. Wird der Child-Socket in der Zwischenzeit abgeräumt, gibt inet_sock_destruct() die Optionen per einfachem kfree() frei – und der SYNACK-Pfad liest Speicher, der schon weg ist.

Die Ursache reicht zurück bis Linux 4.4 (Januar 2016), als Request-Sockets ohne Halten des Listener-Locks verarbeitet werden durften. Betroffen ist alles ab dieser Version ohne den Patch, auf einem Host, der IPv4-TCP-Verbindungen annimmt. Der Hauptpfad braucht keine Sonderkonfiguration; nur ein zweiter, engerer Pfad über Request-Socket-Migration setzt net.ipv4.tcp_migrate_req=1 oder ein BPF-Programm voraus, beides standardmäßig aus. IPv6 umgeht den Hauptpfad, weil dort die Optionen kopiert werden.

Die Behauptung

Am 27. Oktober veröffentlichte Anthropics Frontier Red Team einen Beitrag, in dem es heißt, ein nicht veröffentlichtes internes Forschungsmodell des Hauses habe einen funktionierenden Exploit geschrieben, der aus der Ferne ohne Zugangsdaten als root Befehle ausführt – gegen Server mit einem Multipath-TCP-Listener. Zwei Stufen: Das Gewinnen des Rennens lässt den Kernel eine vom Angreifer kontrollierte Längenangabe lesen und zusätzliche Bytes in das SYNACK kopieren; sobald eine Antwort einen Kernel-Zeiger trägt, ist KASLR ausgehebelt. Danach überschreibt derselbe Fehler einen Callback-Zeiger mit der Adresse einer bereits im Kernelspeicher platzierten Nutzlast, und beim Aufruf läuft ein Befehl nach Wahl als root. Laut Anthropic dauerte das Adressleck 48 Minuten, die Ausführung fünf weitere.

Der Beitrag nennt weder Code noch Kernelversion noch getestete Konfiguration und sagt nicht, ob Hosts ohne MPTCP-Listener ebenso angreifbar sind. TuxCare hat den Exploit nicht nachgebaut; bis Ende Oktober gab es keine unabhängige öffentliche Reproduktion. Die Beschreibung passt allerdings zu dem, was das Kernel-Team selbst in die CVE-Notiz geschrieben hat: alte Optionen leaken benachbarten Kernel-Heap und steuern Out-of-Bounds-Schreibvorgänge. Kein Zero-Day – der Fix war vor der CVE da –, aber auch keine reine Theorie.

Warum MPTCP plötzlich zählt

MPTCP erlaubt einer Verbindung, mehrere Netzwerkpfade gleichzeitig zu nutzen. Anwendungen müssen es beim Öffnen eines Sockets anfordern, jahrelang konnte man also annehmen, es nirgends zu fahren. Go hat das geändert: Seit Go 1.24 aktivieren Go-Programme unter Linux MPTCP auf Listening-Sockets standardmäßig, wenn der Kernel es unterstützt. Ein API-Gateway, Reverse Proxy oder interner Dienst, mit Go 1.24 oder neuer gebaut, kann also einen MPTCP-Listener halten, den niemand bestellt hat. Das Go-Security-Team empfiehlt GODEBUG=multipathtcp=0 zur Laufzeit oder godebug multipathtcp=0 in der go.mod und nennt das selbst eine fragile Maßnahme – ein einzelner verbliebener Listener genügt. Wichtiger noch: Der Fehler ist nicht MPTCP-spezifisch, und Systeme ohne MPTCP-Listener könnten über ähnliche Wege angreifbar sein.

Enterprise-Linux entschärft das teilweise: RHEL 8, 9 und 10 liefern mit deaktiviertem MPTCP aus, ein Go-Dienst fällt dort still auf normales TCP zurück, sofern niemand net.mptcp.enabled=1 gesetzt hat.

Der Streit um die Note

Das Kernel-Team bewertet 9.8: Netzwerkangriffsvektor, keine Rechte, geringe Komplexität – beide Seiten des Rennens seien vom Angreifer ausgelöst, weil er SYN, Retransmit und Verbindungsabbau kontrolliert. Ubuntu zeigt dieselbe 9.8. Red Hat startete bei Moderate (5.9), hob am 29. Oktober auf Important (8.1) an; Oracle, SUSE und Amazon liegen ebenfalls bei 8.1. Der Unterschied ist ein einziger Messwert: Angriffskomplexität hoch statt gering. Technisch vertretbar bei einem Rennen – praktisch weniger, wenn ein verlorenes Rennen den Angreifer nur eine Verbindung kostet. Wer Patch-SLAs nach Hersteller-Schweregrad taktet, hat diesen Fall im Oktober womöglich als "Moderate" einsortiert.

Was jetzt zu tun ist

Erst prüfen: uname -r, sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req, und ss -H -lMn – jede Zeile, die dieses Kommando ausgibt, ist ein MPTCP-Listener. Wo nichts MPTCP braucht: sysctl -w net.mptcp.enabled=0 und dauerhaft in /etc/sysctl.d/ eintragen, danach Dienste neu starten, die bereits Listener geöffnet haben. Zweite Ebene für Hosts ohne festen Kernel ist eine Firewall-Regel, die eingehende TCP-Pakete mit IPv4-Optionen verwirft: nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop. Sie ist nicht gegen einen Exploit getestet, blockiert aber den dokumentierten Auslöser; im Staging prüfen, ob etwas Legitimes bricht. Und dann: feste Kernel installieren, sobald sie erscheinen, mit Reboot oder rebootless Patch.

Der unangenehme Teil bleibt der Zeitplan. Koordinierte Offenlegung hat hier funktioniert – Fix zuerst, CVE danach, Exploit-Code zurückgehalten. Ein Zwei-Zeilen-Fix im Upstream wird aber erst zu einem Hersteller-Kernel, dann zu einem Paket, dann zu einem Reboot auf jedem exponierten Host. Solange Ubuntu und Red Hat keine Termine nennen, entscheidet diese Lücke, nicht der CVSS-Score, wie lange Enterprise-Systeme exponiert bleiben.