CVE-2026-98432: Kernel-Lücke im TCP-Handshake, und was unsere Flotte dazu sagt

Seit dem 15. Oktober 2026 steht CVE-2026-98432 im Kernel-Verzeichnis, mit CVSS 9.8: ein Use-after-free im IPv4-TCP-Handshake, aus der Ferne und ohne Anmeldung auslösbar. Die Korrektur steht im Kernel, die Distributionen liefern sie gerade aus. Ubuntu 26.04, auf dem unsere Mail- und KI-Server laufen, wartet laut Ubuntu-Tracker noch. Dieser Beitrag hält fest, was die Primärquellen hergeben, was nur ein Hersteller behauptet und was wir am 2. November auf vier eigenen Servern gemessen haben.

CVE-2026-98432 ist ein Speicherfehler in tcp_v4_syn_recv_sock(). Ein SYN-Paket mit IP-Optionen trifft auf ein zweites, wiederholtes SYN, und der Kernel greift auf bereits freigegebenen Speicher zu. Betroffen sind Kernel seit Version 4.4. Der Fehler verlangt weder MPTCP noch eine Anmeldung, es genügt ein erreichbarer IPv4-Port.

Aktualisiert am 5. November 2026: Wir haben alle Quellen neu gelesen. Korrigiert sind die Wertung von Oracle und die Priorität der Filterregel von Red Hat. Entfernt sind die Namen zu Patch und Meldung, weil wir sie nicht belegen konnten. Neu sind die Tabelle der Distributionen und der Stand beim Ubuntu-Tracker.

Was der Fehler im Kern ist

Beim Verbindungsaufbau gibt tcp_v4_syn_recv_sock() die IP-Optionen der Anfrage an den neuen Socket weiter, ohne sie zu kopieren. Kommt auf einer anderen CPU ein wiederholtes SYN an, baut ip_options_build() die Antwort aus Speicher, der in diesem Moment freigegeben wird. Das ist ein Rennen zwischen zwei CPUs. Der Fix (Commit e3f33b0a1d89, laut Debian-Tracker ab Kernel 7.3-rc7) ersetzt das kfree durch kfree_rcu, der Speicher bleibt also, bis niemand mehr darauf zeigt. Anthropic führt den Fund in seinem Beitrag auf sein KI-Modell zurück (Herstellerangabe). Wer den Patch geschrieben hat, konnten wir nicht prüfen: git.kernel.org liegt hinter einer Bot-Sperre und lieferte uns nur die Sperrseite. In die Stable-Zweige ist der Fix übernommen, laut CVE-Eintrag etwa mit 5.10.272, 6.1.190, 6.12.113, 6.18.56 und 7.2.10.

Nötig ist ein SYN mit IP-Optionen wie Record Route oder Timestamp, an irgendeinen offenen Port. Ein zweiter Weg über net.ipv4.tcp_migrate_req=1 oder ein BPF-Migrationsprogramm ist laut AlmaLinux standardmäßig aus. IPv6 ist für den ersten Weg ausgeschlossen, laut Commit bleibt aber ein Problem in der CALIPSO-Migration, für das ein eigener Patch folgt. Die Kernel-CNA beschreibt außerdem einen Absturz aus der Ferne (skb_under_panic), der ganz ohne Codeausführung auskommt.

MPTCP: der Teil, den viele Zusammenfassungen falsch gewichten

Etliche Zusammenfassungen stellen MPTCP in den Mittelpunkt. Die Primärquellen tun das nicht. Weder Commit noch CVE-Eintrag erwähnen MPTCP. Das Go-Team schreibt am 29. Oktober auf oss-security, der Fehler sei nicht MPTCP-spezifisch, auch Systeme ohne MPTCP-Listener könnten für ähnliche Angriffe anfällig sein. Red Hat geht weiter: RHEL liefert MPTCP abgeschaltet aus und ist trotzdem verwundbar, und ein Test auf MPTCP-Listener sei kein Nachweis von Sicherheit. Anthropic hat MPTCP für seinen Exploit als Weg gewählt. Eine Bedingung des Fehlers ist es laut Commit und CVE-Eintrag nicht.

Das ändert unsere eigene Vorabmessung. Wir hatten zunächst festgestellt, dass auf keinem Host ein MPTCP-Listener lauscht, und das als Entlastung gelesen. Diese Lesart hält nicht, denn zählen muss jeder IPv4-TCP-Listener.

Was belegt ist und was nur ein Hersteller sagt

Alle Zeilen stammen aus den verlinkten Herstellerseiten, gelesen am 5. November 2026. Nachgebaut oder nachgemessen haben wir davon nichts.

Die Exploit-Behauptung hat genau eine Quelle: den Beitrag des Unternehmens, das den Fehler gefunden hat. Laut diesem Beitrag hat ein unveröffentlichtes internes Modell den Exploit geschrieben. Kernel-Version, Konfiguration und Code hat Anthropic dort nicht veröffentlicht. Go und Red Hat verweisen auf die Beschreibung, bauen sie aber nicht nach. Falsch muss sie deshalb nicht sein, überprüfen können wir sie aber nicht. Dass Amazon den Angriff als schwerer erreichbar einstuft als die Kernel-CNA, ist ein Dissens, den ein Bericht nicht glattbügeln sollte.

Was unsere vier Ubuntu-Server zeigen

Wir betreiben vier Server mit Ubuntu 26.04: den LiteLLM-Router, zwei Mail-Gateways und die TMS-Weboberfläche. Am 2. November 2026 haben wir sie nur lesend per SSH abgefragt. Die Zahlen sind unsere eigene Messung, die Messträger sind genau diese vier Hosts.

Die Korrektur steckt in 7.0.0-43.43, und die war am 2. November bei uns nicht im Index. Beim Ubuntu-Tracker steht 26.04 auch am 5. November noch als verwundbar („work in progress“ in 7.0.0-43.43). Ob unser apt-Index inzwischen einen Kandidaten zeigt, haben wir nach dem 2. November nicht erneut gemessen. Die Lücke ist damit offen, solange Ubuntu nicht liefert.

Wie das Ganze von außen aussieht, wissen wir nicht: Ob ein SYN mit IP-Optionen den Weg durch das Internet und durch unsere Firewall am Rand überlebt, haben wir nicht gemessen. Solche Pakete werden von Netzgeräten häufig verworfen, ein Beleg dafür ist das aber nicht. Offen ist auch, ob eines unserer Programme einen MPTCP-Listener öffnet. Laut Go-Sicherheitsteam aktivieren Go-Programme seit Go 1.24 auf Linux standardmäßig MPTCP für Listen-Sockets. Eine Prüfung mit ss -Mlnp haben wir nicht festgehalten.

Wer schon liefert

Die Tabelle fasst zusammen, was die Hersteller am 5. November 2026 veröffentlicht haben. Wir haben diese Kernel nicht getestet.

Was wir tun, und was wir noch nicht getan haben

Geändert haben wir am 2. November nichts. Ein Kernel-Neustart braucht bei uns eine Freigabe. Folgende Schritte stehen an:

• Täglich nachsehen: Sobald linux-image-generic 7.0.0-43.43 im Index liegt, einspielen und neu starten, zuerst auf den Servern mit dem geringsten Schaden.
• Filter vorbereiten: Red Hat (RHSB-2026-016) und AlmaLinux nennen als Zwischenlösung eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft (ip protocol tcp ip hdrlength > 5 drop). Red Hat hängt sie in eine Kette mit Hook input und Priorität -310, AlmaLinux in prerouting mit -300. Beide schreiben, dass sie das Risiko senkt und den Fehler nicht ausschließt. Nach AlmaLinux kann Verkehr zwischen Containern auf demselben Host die Regel umgehen, weitergeleitete Pakete werden ebenfalls verworfen (auf einem Router also tabu), und sie stört Setups mit CIPSO.
• net.mptcp.enabled=0 schließt nur den gezeigten Angriffsweg und wirkt nach Red Hat nur auf neu angelegte Sockets, laufende Dienste müssen neu starten. Das ist billig und umkehrbar und ersetzt den Patch nicht.
• tcp_migrate_req auf 0 lassen.

Wie ein Mittelstandsbetrieb Updates und Neustarts sauber aufsetzt, steht in unserem Beitrag zu Update- und Neustartabläufen im Mittelstand. Warum ein einzelner Host eine ganze Patch-Runde aufhalten kann, zeigt der Fall mit apt-Exit 100. Weitere Texte stehen im Themenbereich Security und Datenschutz. Wer Server- und Patch-Betrieb auslagern will, findet unsere IT-Leistungen.

Was offen bleibt

Offen sind für uns drei Dinge. Erstens der Veröffentlichungstag von 7.0.0-43. Zweitens, ob Canonical Livepatch den Fix abdeckt, weil ein Livepatch den Neustart ersparen würde. Drittens, wie viel an der Exploit-Behauptung stimmt, solange niemand sie nachbaut. Unsere Empfehlung: den Kernel einspielen, sobald Ubuntu ihn liefert, im nächsten Wartungsfenster mit Neustart, und bis dahin die Filterregel nur auf Hosts setzen, die weder Router sind noch CIPSO nutzen.

Weiterführende Quellen

• CVE-Eintrag CVE-2026-98432 (Kernel-CNA, 15.10.2026)
• Kernel-Commit e3f33b0a1d89 (Fix mit kfree_rcu; die Seite liegt hinter einer Bot-Sperre)
• Ubuntu Security Tracker und Debian Security Tracker
• Red Hat RHSB-2026-016, Red Hat Security Data und der AlmaLinux-Beitrag mit den nftables-Regeln
• Amazon Linux Security Center und Oracle Linux CVE-Seite
• NVD-Eintrag per API und CISA-KEV-Katalog
• oss-security, 29./30.10.2026 (Go-Team zu MPTCP)
• Anthropic zum Fund (Herstellerangabe, 27.10.2026)