Red Hat hatte das Problem zunächst als „Moderate" mit 5,9 Punkten eingestuft, die Bewertung inzwischen aber auf 9,8 angehoben und stuft es nun als kritisch ein. Der Fehler steckt seit Linux 4.4 im Code, der Upstream-Fix erschien im Oktober.
Technisch übergibt der Kernel beim Annehmen einer eingehenden IPv4-TCP-Verbindung die IP-Optionen aus der Anfrage an den neuen Socket, ohne sie zu kopieren. Sendet der Client seine Verbindungsanfrage erneut, während ein anderer Prozessorkern diese Optionen noch liest, kann der Kernel bereits freigegebenen Speicher lesen. Auslösen lässt sich das Wettrennen, indem ein Angreifer Verbindungsanfragen mit den IPv4-Optionen Record Route oder Timestamp an einen beliebigen lauschenden TCP-Port schickt. Eine Anmeldung ist nicht nötig. IPv6 ist auf dem Hauptpfad nicht betroffen.
Red Hat veröffentlichte am 1. November die Errata RHSA-2026:93414 (RHEL 8), RHSA-2026:93412 (RHEL 9) und RHSA-2026:93413 (RHEL 10). Nach der Installation ist ein Neustart erforderlich.
Canonical teilte am 2. November mit, dass die Korrekturen für Ubuntu 22.04 LTS, 24.04 LTS und 26.04 LTS im -proposed-Pocket liegen, einem Testkanal, den Nutzer ausdrücklich aktivieren müssen. Pakete von dort werden nicht automatisch installiert. Canonical testet Kernel-Updates vor der Freigabe in den regulären Kanal auf mehr als 2.000 zertifizierten Servern und Geräten; ein Freigabetermin wurde nicht genannt. Wer den Fix früher braucht, kann -proposed aktivieren und das Kernel-Update einspielen; ob ein System einen korrigierten Kernel verwendet, lässt sich über die Ausgabe von uname -r prüfen.
Für Ubuntu 20.04, 18.04 und 16.04 gibt es bislang keinen Fix; ältere Versionen benötigen Expanded Security Maintenance über Ubuntu Pro. Die Cloud-, FIPS- und Echtzeit-Kernelvarianten sind auf der Ubuntu-CVE-Seite mit Zielversionen als in Arbeit gelistet, der Beitrag von Canonical behandelt nur den generischen Kernel.
Als Übergangsmaßnahme veröffentlichte Red Hat am 30. Oktober eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft. Sie blockiert laut Red Hat den bekannten Auslöser des Wettrennens, kann eine Ausnutzung aber nicht vollständig verhindern und kann Anwendungen stören, die auf IPv4-Optionen angewiesen sind. Der Filter wirkt zudem nur auf dem Host, auf dem er geladen ist; Verkehr zwischen Containern auf demselben Host kann ihn umgehen, wie ein Mitglied des CIQ-Kernel-Teams auf der Mailingliste oss-security anmerkte.
Mehrfach wurde empfohlen, Multipath TCP (MPTCP) abzuschalten. Die Lücke sitzt jedoch im IPv4-TCP-Pfad und nicht in MPTCP; dieser Rat allein reicht nach Darstellung von Canonical nicht aus. „Das Ubuntu-Sicherheitsteam ist der Auffassung, dass Sicherheitsupdates die einzige angemessene Gegenmaßnahme sind", heißt es dort.
Angriffe über die Schwachstelle hat bislang weder ein Hersteller noch ein CERT oder das Kernel-CVE-Team gemeldet. Im Katalog bekannter ausgenutzter Schwachstellen der CISA war sie im Stand vom 30. Oktober nicht enthalten.
Anthropic erklärte am 27. Oktober, ein unveröffentlichtes, internes Claude-Forschungsmodell habe einen Remote-Root-Exploit für die Lücke geschrieben, der gegen Linux-Server mit einem MPTCP-Listener funktioniere – ohne Zugangsdaten und ohne Nutzerinteraktion. Im Proof of Concept dauerte das Auslesen einer Kernel-Adresse 48 Minuten, bis zur Root-Shell vergingen weitere fünf Minuten. Den Exploit-Code hat Anthropic nicht veröffentlicht. Auf GitHub ist Code aufgetaucht, der das Wettrennen auslöst und erkennt, dass der Kernel freigegebenen Speicher in einem SYN-ACK zurückgibt; eine Codeausführung setzt er nicht um.
Amazon Linux bewertet die Lücke mit 8,1 Punkten als „Important" und nennt als wesentliche Folge einen Absturz mit möglicher Speicherkorruption; dort wurden zwischen dem 24. und 30. Oktober alle Pakete korrigiert. Debian, Oracle Linux und SUSE lieferten ihre Fixes im Oktober aus.