Die Schwachstelle CVE-2026-98432 im IPv4-TCP-Netzwerkstack des Linux-Kernels ermöglicht es einem entfernten, nicht authentifizierten Angreifer, durch eine Race Condition bei der Verarbeitung von TCP-Verbindungen die Ausführung beliebigen Codes zu erreichen. Das Problem betrifft alle Kernel-Versionen ab 4.4 und jede Systeme mit einem offenen TCP-Port, der IPv4-Verbindungen entgegennimmt. Red Hat und Canonical stufen die Schwachstelle als kritisch mit einem CVSS-Score von 9.8 ein. Patches sind bereits für RHEL, Amazon Linux und teilweise für Ubuntu verfügbar; Administratoren müssen den Kernel aktualisieren und die Systeme neu starten.
Technischer Kern der Schwachstelle
Das Problem gehört zur Klasse use-after-free und tritt in der Funktion tcp_v4_syn_recv_sock() auf. Beim Annehmen einer eingehenden IPv4-TCP-Verbindung übergibt der Kernel die IP-Optionen vom anfragenden Socket an den Kind-Socket, ohne sie zu kopieren. Wenn der Client das SYN-Paket erneut sendet, während ein anderer Prozessor diese Optionen noch liest, greift der Kernel in der Funktion ip_options_build() auf bereits freigegebenen Speicher zu. Kind-TCP-Sockets besitzen das Flag SOCK_RCU_FREE nicht, und der Destruktor inet_sock_destruct() gibt inet_opt mit einem normalen kfree() statt mit kfree_rcu() frei.
Ein Angreifer triggert die Race Condition, indem er TCP-Verbindungsanfragen mit den IPv4-Optionen Record Route oder Timestamp an einen beliebigen lauschenden TCP-Port sendet. Eine Authentifizierung ist nicht erforderlich. Ein ähnliches Problem besteht bei der Migration von Request-Sockets (net.ipv4.tcp_migrate_req=1). Nach Angaben von Canonical ist IPv6 nicht von dem eigentlichen Problem betroffen, da der IPv6-Verarbeitungspfad die Optionen dupliziert.
Die Fehlerbehebung besteht darin, kfree() durch kfree_rcu() in inet_sock_destruct() und tcp_v4_reqsk_destructor() zu ersetzen, sodass der Speicher erst nach Ablauf der RCU Grace Period freigegeben wird.
Unterschiede bei der Bewertung der Schwere
Auffällig ist, dass sich die Hersteller bei der Bewertung der Kritikalität unterscheiden. Fortinet, Red Hat und Ubuntu vergeben CVSSv3 9.8 und den Status Critical und verweisen auf die Möglichkeit von Remote Code Execution. Amazon Linux bewertet die Schwachstelle hingegen mit 8.1 (Important) und hebt Denial of Service und mögliche Speicherbeschädigung als Hauptfolgen hervor. Diese Differenz spiegelt die unterschiedliche Einschätzung der praktischen Ausnutzbarkeit wider: Die Race Condition erfordert präzises Timing, und nicht jeder Hersteller hält ein zuverlässiges Erreichen von RCE für garantiert.
Status der Ausnutzung
Nach Angaben von Fortinet wurde die Schwachstelle bisher nicht in aktiven Angriffen beobachtet. Canonical berichtet, dass neben der internen Forschung von Anthropic keine weiteren Exploits bekannt sind. Auf GitHub wurde Code veröffentlicht, der die Race Condition demonstriert und einen Zugriff auf freigegebenen Speicher im SYN-ACK erkennt, jedoch ohne Implementierung von Codeausführung. Wir haben bereits berichtet, dass ein internes Forschungsmodell von Anthropic einen funktionierenden Exploit für diese Schwachstelle erstellt hat, mit dem Root-Zugriff auf Server mit MPTCP-Listener ohne Authentifizierung erlangt werden kann. Der Exploit-Code wurde nicht veröffentlicht.
Betroffene Systeme und verfügbare Patches
Die Schwachstelle betrifft ein breites Spektrum von Linux-Distributionen:
- Red Hat Enterprise Linux 8, 9, 10 und die Red Hat OpenShift Container Platform – Patches wurden am 1. November veröffentlicht (RHSA-2026:93414, RHSA-2026:93412, RHSA-2026:93413). Red Hat weist außerdem darauf hin, dass Produkte auf Basis des RHEL-Kernels, darunter Red Hat OpenStack Platform und Red Hat Virtualization, betroffen sein können.
- Ubuntu 22.04, 24.04, 26.04 LTS – Fixes stehen im -proposed-Channel zur Verfügung (Kernel-Versionen 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43 entsprechend). Pakete aus -proposed werden nicht automatisch installiert. Ubuntu 26.10 ist im Hauptkanal behoben. Für Ubuntu 20.04 und ältere Versionen gibt es bisher keine Patches.
- Amazon Linux 2 und Amazon Linux 2023 – Fixes wurden zwischen dem 24. und 30. Oktober veröffentlicht.
- Fortinet – prüft die Auswirkungen auf mehr als 50 Produkte, darunter FortiOS, FortiGate Cloud, FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiSIEM und weitere. Status der Untersuchung: läuft noch.
Empfehlungen zum Schutz
Ein Kernel-Update mit anschließendem Neustart ist die einzige vollständige Lösung, wie sowohl Red Hat als auch Canonical betonen. Bis zur Installation des Patches stehen temporäre Maßnahmen zur Verfügung, die das Risiko verringern, es aber nicht beseitigen:
Filterung von IPv4-TCP-Paketen mit IP-Optionen. Red Hat hat folgende nftables-Regel veröffentlicht:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}Diese Regel blockiert den bekannten Angriffsvektor, hat aber Einschränkungen: Sie wirkt nur auf dem Host, auf dem sie geladen ist, und filtert keinen Traffic zwischen Containern auf demselben Host. Außerdem kann die Regel den Betrieb von Anwendungen beeinträchtigen, die IPv4-Optionen verwenden.
Die Deaktivierung von MPTCP ist keine ausreichende Maßnahme. Red Hat weist ausdrücklich darauf hin, dass MPTCP keine Voraussetzung für die Schwachstelle ist – Systeme mit deaktiviertem MPTCP bleiben verwundbar. Canonical bestätigt: „Das Ubuntu-Sicherheitsteam ist der Ansicht, dass Sicherheitsupdates die einzige angemessene Schutzmaßnahme sind.“
Zur Prüfung der aktuellen Kernel-Version können Sie uname -r verwenden und das Ergebnis mit den Versionen der behobenen Pakete für Ihre Distribution vergleichen.
Angesichts des vorhandenen öffentlichen PoC-Codes, der die Race Condition demonstriert, der kritischen Bewertung durch die meisten Hersteller und der Breite der betroffenen Systeme – von Servern bis zu Container-Plattformen – sollte das Kernel-Update als vorrangige Aufgabe betrachtet werden. Administratoren von RHEL sollten die veröffentlichten Patches umgehend installieren; Administratoren von Ubuntu, die nicht auf die Bereitstellung der Pakete aus -proposed im Hauptkanal warten können, sollten die Möglichkeit eines frühzeitigen Upgrades über -proposed unter Berücksichtigung der Risiken des Testkanals prüfen.
