Die Lücke steckt im Code, der neue IPv4-TCP-Verbindungen aufbaut. Durch die Race Condition kann der Kernel bereits freigegebenen Speicher lesen – ein Use-after-Free. Der Fehler tritt während des TCP-Handshakes auf: Ist eine Verbindung abgeschlossen, übergibt der Kernel die zum wartenden Request gespeicherten IP-Optionen an den neuen Socket, ohne sie zu kopieren. Wird dieser Socket zerstört, während eine andere CPU die Optionen noch nutzt, um auf einen erneut gesendeten Verbindungswunsch zu antworten, liest der Kernel freigegebenen Speicher. IPv6 ist nicht betroffen, weil der Kernel die Optionen dort kopiert.
Eingeführt wurde der Fehler mit Linux 4.4. Kernel-Entwickler nahmen den Fix am 5. Oktober auf, zehn Tage vor der Veröffentlichung des CVE-Eintrags. Die Korrektur lässt den Kernel warten, bis andere CPUs das Lesen der Optionen beendet haben, bevor er sie freigibt. Als Melder des Fehlers nennt der Kernel-Fix den Anthropic-Forscher Xinyang Ge. Weder der CVE-Eintrag noch der Fix erwähnen Multipath TCP (MPTCP); diese Verbindung stellt allein Anthropic her. MPTCP erlaubt es, eine Verbindung über mehrere Netzwerkpfade zu führen; unter Linux muss eine Anwendung MPTCP beim Öffnen eines Sockets ausdrücklich anfordern.
Stark auseinander gehen die Bewertungen. Das CVE-Team des Kernels trug die 9,8 am 24. Oktober nach, neun Tage nach Veröffentlichung des Eintrags. Es unterstellt einen Angreifer, der einen TCP-Verbindungswunsch mit den IPv4-Optionen Record Route oder Timestamp sendet und den Request anschließend erneut schickt, um das Rennen zu gewinnen. Die Angriffskomplexität stuft das Team als niedrig ein, da beide Seiten des Rennens „vom Angreifer herbeigeführt" seien. Mögliche Folgen: Rückgabe benachbarten Kernel-Speichers an den Angreifer, Speicherkorruption oder ein Systemabsturz.
Stand 28. Oktober hatte die National Vulnerability Database keine eigene Bewertung ergänzt und zeigte die 9,8 des Kernel-Teams; auch die Ubuntu-Seite weist diesen Wert aus. Red Hat stuft die Lücke auf seiner CVE-Seite als „Moderate" mit 5,9 ein, weil das Rennen schwer zu gewinnen sei. Wahrscheinlichste Folge sei ein Kernel-Absturz, Speicherkorruption theoretisch möglich; „es wurde keine Auswirkung auf Vertraulichkeit oder Integrität nachgewiesen". Die maschinenlesbare Advisory-Datei von Red Hat, aktualisiert am 29. Oktober, führt die Auswirkung dagegen als „Important" und bewertet mit 8,1 bei hoher Vertraulichkeits- und Integritätsauswirkung. Am selben Tag änderte Red Hats Bugtracker die Einstufung von mittel auf hoch, während die CVE-Seite weiter „Moderate" und 5,9 zeigte.
Oracle und SUSE bewerten die Lücke ebenfalls mit 8,1 und demselben CVSS-Vektor wie Red Hats Advisory-Datei. Diese Bewertungen decken sich in allen Metriken mit der des Kernel-Teams, außer bei der Angriffskomplexität: Die Hersteller stufen sie als hoch ein, das Kernel-Team als niedrig. Amazon vergibt 7,0. Insgesamt liegen Red Hat, Amazon, Oracle und SUSE mit 5,9 bis 8,1 unter den 9,8 des Kernel-Teams.
Anthropic beschrieb den Linux-Exploit in einem Beitrag vom 27. Oktober über Schwachstellen, die das Modell Claude gefunden und ausgenutzt hat. Claude habe den Exploit nach „anfänglichem Prompting" geschrieben. Der Angriff läuft in zwei Stufen: Zunächst sorgt das Rennen dafür, dass der Kernel zusätzliche Bytes an den Angreifer zurücksendet; enthält eine dieser Antworten eine Kernel-Adresse, lässt sich KASLR, die Adressraum-Randomisierung des Kernels, umgehen. In der zweiten Stufe überläuft derselbe Fehler einen Puffer und überschreibt einen Callback-Zeiger mit der Adresse einer zuvor im Kernel-Speicher platzierten Payload. Ruft der Kernel diesen Zeiger auf, führt die Payload einen beliebigen Shell-Befehl als root aus.
Ein verlorenes Rennen lasse lediglich den einzelnen Verbindungsversuch scheitern und bringe das System nicht zum Absturz, sodass ein Angreifer es beliebig oft erneut versuchen könne, so das Unternehmen. Im Test dauerte das Auslesen einer Kernel-Adresse 48 Minuten, bis zur Befehlsausführung vergingen weitere fünf Minuten. Exploit-Code, die getestete Kernel-Version und die Konfiguration nennt der Beitrag nicht.
Nach Angaben von Red Hat kann ein entfernter Angreifer, der einen exponierten TCP-Dienst erreicht, das Rennen auslösen. Anthropics Root-Exploit zielte dagegen auf Server mit einem Multipath-TCP-Listener; ob Server ohne einen solchen ebenso übernommen werden können, bleibt offen.
Stand 29. Oktober berichten weder die Hersteller-Advisories noch der CVE-Eintrag oder Anthropics Beitrag von Angriffen mit der Lücke. In einer Kopie des CISA-Katalogs bekannter ausgenutzter Schwachstellen, die das luxemburgische CIRCL zuletzt am 28. Oktober aktualisiert hat, taucht sie nicht auf.
Anthropic schreibt, der Fehler sei „upstream gepatcht und in alle gepflegten stabilen Kernel-Zweige zurückportiert" worden. Für Distributionsnutzer kommt der Fix allerdings erst mit dem Kernel-Paket des jeweiligen Anbieters. Debian, Oracle Linux, SUSE und Amazon Linux haben korrigierte Pakete ausgeliefert, zumindest für einen Teil ihrer Kernel. Ubuntu führt zusätzlich seine Cloud-, FIPS- und Echtzeit-Kernel als verwundbar oder in Bearbeitung. Red Hat erklärt, seine Fixes seien „derzeit auf ein künftiges Update verschoben". Einen Termin nennt keines der beiden Unternehmen.
Wer seinen Kernel selbst baut, findet den Fix in:
- 5.10.272
- 5.15.223
- 6.1.190
- 6.6.159
- 6.12.113
- 6.18.56
- 7.2.10
- 7.3
Das CVE-Team des Kernels empfiehlt, auf den jeweils aktuellen stabilen Kernel zu aktualisieren; das Herauspicken einzelner Fixes werde von der Kernel-Community nicht unterstützt. Für Ubuntu, RHEL sowie einige Amazon-Linux- und SUSE-Releases gibt es noch keinen korrigierten Kernel. Red Hat erklärt, keine verfügbare Gegenmaßnahme erfülle die eigenen Kriterien für einfache Einspielbarkeit, Eignung für die meisten Installationen und Stabilität; andere Hersteller-Advisories nennen ebenfalls keine. Ob das Abschalten von Multipath TCP oder das Blockieren eingehender Verbindungswünsche mit IP-Optionen das Risiko senkt, sagen weder die Advisories noch Anthropics Beitrag.