CVE-2026-98432 betrifft den IPv4-TCP-Handshake im Linux-Kernel. Eine Use-After-Free-Lücke, die ein entfernter Angreifer ohne Anmeldung auslösen kann. Der Fehler liegt in Code, den jeder Linux-Host beim Aufbau einer TCP-Verbindung durchläuft, bevor eine Anwendung davon etwas merkt. Entscheidend ist deshalb nicht, welcher Dienst auf einem Server lauscht, sondern welcher Kernel darunter läuft.
Die stabilen Kernel-Zweige haben den Fix am 11. und 15. Oktober 2026 ausgeliefert; die Kernel-CNA, also die CVE-Vergabestelle des Linux-Kernels selbst, bewertet die Lücke mit CVSS 3.1 von 9,8 als kritisch. Betroffen sind Kernel ab 4.4, und der Patch ist winzig. Genau das macht die Sache schwierig: Ein Patch von wenigen Zeilen muss über Distributionskernel, Cloud-Images und Container-Hosts hinweg ankommen, und dort gelten eigene Versionsnummern und eigene Zeitpläne.
Wer einen Server betreibt, trifft hier auf eine Lücke, die nicht auf eine Anwendung wartet. Sie sitzt im Netzwerk-Stack, greift vor jeder Authentifizierung und lässt sich nach Einschätzung von Red Hat für Remote Code Execution unter Linux nutzen. Was technisch passiert, welche Systeme betroffen sind, wie du den Stand deiner Maschinen prüfst und was ohne Patch deiner Distribution hilft, steht in den folgenden Abschnitten.
Was der Kernel bei IPv4-TCP-Optionen im Handshake tut
Der Fehler lässt sich mit einer Anmeldung am Empfang vergleichen. Ein Client schickt beim Verbindungsaufbau ein SYN-Paket. Stecken im IPv4-Header Optionen – etwa Record Route oder Timestamp –, sind das die Sonderwünsche auf dem Anmeldeformular. Der Kernel legt diese Daten in einem provisorischen Vorgang ab, dem Request-Socket, der den halboffenen Handshake verwaltet. Erst wenn der Handshake abgeschlossen ist, entsteht daraus der vollwertige Socket.
Für die Antwort an den Client spiegelt der Kernel die Optionen zurück. Dafür muss er den Zettel mit den Sonderwünschen weiter lesen können. Hier passiert der Fehler: Die gespeicherten Optionsdaten wandern vom Request-Socket in die neue Verbindung, ohne kopiert zu werden. Wird die Verbindung abgebaut, gibt der Kernel den Speicher sofort frei – während ein anderer Prozessor denselben Speicher noch liest, um eine Handshake-Antwort zu bauen. Das ist ein tcp use-after-free: Gelesen wird, was an dieser Stelle nicht mehr zum eigenen Vorgang gehört.
Der Aufwand für einen Angreifer ist gering, weil weder Konto noch Zertifikat nötig sind. Ein verlorenes Rennen im Wettlauf um den Speicher führt laut Anthropic nur zu einem fehlgeschlagenen Handshake, nicht zum Absturz – ein Angreifer kann es also beliebig oft wiederholen. Nach den Bewertungsnotizen der Kernel-CNA kann er dabei Kernel-Heap-Inhalte an sich zurückgespielt bekommen, Schreibvorgänge im Kernel aus dem erlaubten Bereich lenken oder die Maschine zum Absturz bringen. Red Hat formuliert es in seinem Bulletin noch direkter und nennt eine Race Condition bei der Verarbeitung von TCP-Verbindungswünschen, die Remote Code Execution ermöglicht.
Der Fix ist klein – wirksam wird er erst nach dem Reboot
Eric Dumazet hat den Patch geschrieben, mit dem Titel „ipv4: free inet_opt and ireq_opt after an RCU grace period“. Statt die Optionsdaten mit einem einfachen kfree() sofort freizugeben, verwendet der Code kfree_rcu(), also eine Freigabe erst nach einer RCU-Grace-Period. Übersetzt in das Bild vom Empfang: Der Zettel geht erst in den Schredder, wenn der letzte Leser ihn zurückgelegt hat. Andere Codepfade, die diese Optionen ersetzen, arbeiteten schon vorher so; der Patch zieht die beiden Ausnahmen nach.
Die Änderung betrifft zwei Dateien und zwei Aufrufe, verteilt auf net/ipv4/af_inet.c und net/ipv4/tcp_ipv4.c. Sie deckt zusätzlich die Migration von Request-Sockets ab, also den Fall, dass ein Socket per net.ipv4.tcp_migrate_req=1 oder über ein BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE weiterwandert. Ein verwandter Fall für IPv6 wird laut Commit in einem separaten Patch behandelt; die Hauptlücke betrifft IPv4. Für Betreiber heißt das: Eine aktualisierte Kernel-Version allein genügt nicht, wenn die Maschine noch in den alten Kernel gebootet ist.
Welche Kernel und Distributionen den Patch haben
Upstream sind die festen Stände 7.3, 7.2.10, 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223 und 5.10.272. Die Reihen 7.2 und älter sind upstream teilweise bereits am Ende ihres Lebenszyklus; Zweige, die vor 5.10 eingestellt wurden, bekommen keinen eigenen Fix mehr und sind auf Distributions-Patches angewiesen. Für die Praxis ist die Upstream-Nummer nur ein Hinweis, denn Distributionen tragen Fixes unter eigenen Versionsnummern ein.
Red Hat hat die Lücke am 30. Oktober von Important (8,1) auf Critical (9,8) hochgestuft und am 1. November feste Kernel für RHEL 8.10, 9.8 und 10.2 veröffentlicht, inklusive der Echtzeit-Kernel. OpenShift Container Platform über RHEL CoreOS und RHEL for NVIDIA gelten weiterhin als betroffen, ebenso ein separates kernel-rt-Paket für RHEL 9; RHEL 6 und 7 sind laut CVE-Seite nicht betroffen. AlmaLinux hat feste Kernel für 8, 9 und 10 seit dem 30. Oktober im Test-Repository, aber noch nicht in Produktion. Debian hat die Lücke in Bookworm und Trixie geschlossen, SUSE in SLES 16.0 sowie den 15-SP4-bis-SP6-LTSS-Kernels, Oracle Linux über UEK-Erratas vom 16. Oktober und Amazon Linux in allen Kernels für AL2 und AL2023.
Bei Ubuntu sah es am 1. November um 18:15 Uhr CST anders aus: Der Kernel stand in jeder Release noch auf „Vulnerable“, teils mit dem Zusatz „work in progress“, und eine Ubuntu Security Notice war nicht veröffentlicht. Wer Ubuntu einsetzt, muss den Tracker beobachten und darf sich nicht darauf verlassen, dass ein reguläres Update die Lücke schon schließt. Die Unterschiede zwischen den Distributionsangaben sind real und kein Formfehler: Ubuntu bewertet die Lücke mit High, SUSE mit important, Oracle und Amazon mit Important und CVSS 8,1, während Kernel-CNA und Red Hat bei 9,8 liegen. Das NVD wiederum führte den Eintrag am 1. November nur als „Received“, ohne eigene Analyse.
So prüfst du, ob deine Server betroffen sind
Der erste Blick gilt dem laufenden Kernel, nicht dem installierten Paket. Ein Vergleich der Version mit der Liste der Distribution zeigt, ob der Fix enthalten ist; ein neuerer installierter Kernel, in den die Maschine noch nicht gebootet hat, schützt nicht. Diese Prüfung gehört auf Container-Hosts und Kubernetes-Nodes, nicht in die Container hinein, denn ein Container meldet den Kernel des Hosts. Ein neues Image ändert an der Kernel-Sicherheitslücke also nichts.
Der zweite Blick gilt Multipath TCP, weil der veröffentlichte Proof-of-Concept von Anthropic einen MPTCP-Listener voraussetzt. Mit ss -M listet iproute2 ausschließlich MPTCP-Sockets, eine leere Ausgabe bedeutet also keinen MPTCP-Listener; ss -Mlnp zeigt zusätzlich lauschende Sockets und Prozesse. Die Einstellung net.mptcp.enabled = 1 allein genügt nicht, denn eine Anwendung muss einen MPTCP-Socket auch öffnen. Auch Go spielt eine Rolle: Laut Go Security Team aktivieren Go-Programme ab Go 1.24 MPTCP für Listen-Sockets unter Linux standardmäßig, abhängig von der go-Zeile in der go.mod und davon, ob der Kernel MPTCP erlaubt. Das Go-Team betont zugleich, die Lücke sei nicht MPTCP-spezifisch; Systeme ohne MPTCP-Listener könnten ähnlichen Angriffen ausgesetzt sein.
Patch, Reboot und nftables als Übergangslösung
Sobald deine Distribution einen festen Kernel ausliefert, installierst du ihn und startest die Maschine neu – sonst bleibt der alte Kernel aktiv. Das gilt auch für virtualisierte Hosts, Kubernetes-Nodes und Appliances, deren Kernel im Image steckt und nur über den Hersteller kommt. Bei einem selbst gebauten Kernel wechselst du auf den festen Stand der jeweiligen Reihe. AlmaLinux-Nutzer warten auf die Produktions-Repositories, Ubuntu-Nutzer auf die Security Notice, OpenShift-Nutzer auf RHEL CoreOS.
Wer nicht sofort patchen kann, hat eine Notlösung: Red Hat und AlmaLinux veröffentlichen nftables-Regeln, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwerfen. Die Regel prüft die Header-Länge – ip hdrlength gt 5 trifft jedes IPv4-Paket, dessen Header länger als die 20 Byte Minimum ist, und genau das ist bei Optionen der Fall. Red Hat schreibt selbst, die Regel reduziere die Angriffsfläche, verhindere die Ausnutzung aber nicht vollständig. TCP-Verkehr mit IPv4-Optionen ist im Normalbetrieb praktisch nicht anzutreffen, weshalb der Filter selten legitime Verbindungen trifft – prüfen sollte man das trotzdem, bevor man ihn produktiv setzt.
Was das für den Betrieb heißt
Die Lücke dreht die übliche Reihenfolge der Verteidigung um. Firewalls, Authentifizierung und Anwendungshärtung greifen erst, wenn der Handshake längst gelaufen ist – der ipv4 tcp handshake selbst ist die Angriffsfläche. Dass ein KI-Modell laut Anthropic einen funktionierenden Exploit geschrieben hat, verschiebt zusätzlich die Wahrnehmung: Solche Fehler werden schneller gefunden und schneller in lauffähigen Code übersetzt, auch wenn Anthropic den Exploit nicht veröffentlicht hat. Für Betreiber heißt das: Der Patch-Stand des Kernels gehört auf dieselbe Liste wie Backups und Monitoring.
Auch die Bewertung fällt unterschiedlich aus. Wenn Kernel-CNA und Red Hat 9,8 vergeben, Ubuntu High und Oracle 8,1, liegt das an unterschiedlichen Annahmen über Exposition und Ausnutzbarkeit. Für die Priorisierung zählt, ob dein System erreichbar ist, ob es MPTCP-Listener gibt und ob der Kernel gepatcht und gebootet ist. Diese drei Fragen beantworten wenige Befehle.
Quelle: atlasum.net
