KIungefiltert

· 4 Min. Lesezeit · Read in English

Linux-Kernel: Elf Jahre alte TCP-Lücke, gefunden von Claude: was Admins jetzt tun sollten

CVE-2026-98432 im IPv4-TCP-Code des Linux-Kernels: Anthropics Claude fand den Fehler und schrieb einen Root-Exploit. Debian, Oracle und SUSE haben Patches, Ubuntu und RHEL noch nicht.

SicherheitKISelfhosting

Im TCP-Code des Linux-Kernels steckt seit Version 4.4 ein Fehler, also seit gut elf Jahren. Er hat die Kennung CVE-2026-98432, und das Kernel-CVE-Team bewertet ihn mit 9.8 von 10 Punkten. Gefunden hat ihn laut Anthropic dessen KI-Modell Claude, das auch gleich einen funktionierenden Exploit dazu geschrieben hat. Seit meinem ersten Post auf X und im WhatsApp-Kanal sind einige Details dazugekommen. Die wichtigsten: Mehrere Distributionen haben inzwischen Patches, die Einstufung der Schwere ist umstritten, und Multipath-TCP spielt eine Rolle.

Was passiert ist

Betroffen ist der Code, der neue IPv4-Verbindungen aufbaut. Es handelt sich um eine Race Condition: Zwei CPUs greifen gleichzeitig auf dieselben Daten zu, und das Ergebnis hängt davon ab, welche zuerst dran ist. Die Folge ist ein Use-after-free, der Kernel liest also Speicher, den er schon freigegeben hat. Konkret geht es um IP-Optionen aus einer Verbindungsanfrage, die der Kernel an den neuen Socket weiterreicht, ohne sie zu kopieren. The Hacker News und heise berichten übereinstimmend, dass IPv6 nicht betroffen ist, weil der Kernel die Optionen dort kopiert.

Der fehlerhafte Commit stammt laut heise vom Oktober 2015. Im Kernel-Fix wird Anthropic-Forscher Xinyang Ge als Melder genannt. Anthropic schreibt, Claude habe den Exploit nach „initial prompting“ selbst erstellt. Der Exploit arbeitet in zwei Stufen: Zuerst verrät der Kernel Speicheradressen, womit sich KASLR aushebeln lässt (die Zufallsverteilung des Kernels im Speicher). Danach wird ein Funktionszeiger überschrieben, sodass ein Befehl als root läuft. Ein verlorenes Rennen lässt nur den einzelnen Verbindungsversuch scheitern, das System stürzt dabei nicht ab. Ein Angreifer kann es also einfach wieder versuchen. In Anthropics Test dauerte das Adressleck 48 Minuten, die Codeausführung danach noch fünf. Code, Kernelversion und Testaufbau hat Anthropic nicht veröffentlicht.

Wichtig ist eine Einschränkung: Anthropics Exploit zielte auf Server, auf denen ein Dienst über Multipath-TCP (MPTCP) lauscht. Das ist eine TCP-Erweiterung, die eine Verbindung über mehrere Netzwege verteilt. Ob Server ohne MPTCP genauso angreifbar sind, ist offen. Red Hat geht davon aus, dass jeder erreichbare TCP-Dienst reicht, um die Race Condition auszulösen. Go-Programme nutzen MPTCP laut heise standardmäßig.

Warum die Bewertungen so weit auseinandergehen

Die 9.8 stammt vom Kernel-CVE-Team. Andere sehen es anders. Red Hat nennt auf seiner CVE-Seite 5.9, im maschinenlesbaren Advisory 8.1. Oracle und SUSE vergeben 8.1, Amazon 7.0. Der Grund ist vor allem, wie schwer man das Rennen gewinnen kann. Für mich zählt am Ende: Der Angriff läuft aus der Ferne, braucht keine Zugangsdaten, und es gibt einen funktionierenden Root-Exploit, auch wenn der nicht öffentlich ist. Das reicht, um das Update ganz nach oben auf die Liste zu setzen.

Angriffe in freier Wildbahn sind bisher nicht bekannt. Weder Hersteller noch CVE-Eintrag oder Anthropic berichten davon, und im KEV-Katalog der US-Behörde CISA steht die Lücke bislang nicht.

Wer betroffen ist und wo es Patches gibt

Betroffen sind alle Kernel ab 4.4 mit IPv4, also praktisch jeder Linux-Server. Upstream ist der Fehler behoben in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Bei den Distributionen sieht es laut The Hacker News (Stand 29. Oktober) so aus:

  • Debian: Trixie und Bookworm haben Patches.
  • Oracle Linux 7 bis 10 (UEK): Gepatcht seit 16. Oktober.
  • SUSE: openSUSE Leap 16.0 und SUSE Linux Micro 6.2 sind gepatcht, SLES-Versionen sind teils im Test.
  • Amazon Linux 2023: Die Pakete kernel6.18 und kernel6.12 sind gepatcht, der Rest ist noch offen.
  • Ubuntu (16.04 bis 26.10): Noch kein Fix veröffentlicht.
  • RHEL 8, 9, 10 und OpenShift 4: Noch kein Fix. Red Hat hatte die Updates zunächst „auf ein künftiges Update verschoben“. RHEL 7 ist nicht betroffen.

Was du tun solltest

  1. Patchen, sobald es geht. Wo es Updates gibt, einspielen und neu starten. Ein neuer Kernel wirkt erst nach dem Reboot.
  2. Advisories beobachten. Wer Ubuntu oder RHEL nutzt, sollte täglich nachsehen.
  3. Erst die exponierten Systeme. Server, deren TCP-Dienste aus dem Internet erreichbar sind, kommen zuerst dran.
  4. MPTCP prüfen. Für Go-Dienste nennt das Go-Security-Team GODEBUG=multipathtcp=0 als Notlösung. Die Entwickler nennen das selbst fragil, und Systeme ohne MPTCP sind womöglich trotzdem verwundbar. Einen Patch ersetzt das nicht. Red Hat sagt, es gebe keine Mitigation, die seinen Anforderungen genügt.

Einordnung

Ein Fehler, den mehrere Fachleute vor elf Jahren geprüft und durchgewunken haben, wird jetzt von einem KI-Modell gefunden, samt Exploit. heise-Autor Jürgen Schmidt erwartet „eine riesige Welle von Schwachstellen“. Das halte ich für realistisch. Was Verteidiger finden können, finden Angreifer früher oder später auch. Patch-Zyklen von Wochen werden damit zum Risiko.

Quellen