Linux-Kernel CVE-2026-98432: Zwei Sockets teilen sich IP-Optionen, und einer gibt sie zu früh frei

TL;DR — 90 Sekunden

• Was: Ein Use-after-free im IPv4-TCP-Handshake. Request-Socket und Verbindungs-Socket teilen sich die gespeicherten IP-Optionen, und ein parallel gebautes SYNACK kann sie lesen, nachdem sie freigegeben wurden.
• Schwere: Das CNA des Kernels vergibt CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), Amazon kommt wegen hoher Angriffskomplexität auf 8.1, Red Hat führt vorläufig 5.9. Anthropic meldet einen funktionierenden Remote-Root-Exploit gegen MPTCP-Listener, veröffentlicht hat es ihn nicht.
• Wen es trifft: Jeden Kernel ab 4.4 ohne Fix, der IPv4-TCP-Verbindungen aus nicht vertrauenswürdigen Netzen selbst annimmt. Besonders exponiert sind Hosts mit MPTCP-Listenern, die Go-Dienste ab Go 1.24 von sich aus öffnen.
• Was zu tun ist: Einen gepatchten Kernel einspielen und neu starten. Für Amazon Linux 2 und Amazon Linux 2023 sind seit dem 30. Oktober alle Kernel-Pakete gefixt, Debian liefert 6.1.190 und 6.12.113.
• Was vorher geschützt hätte: TCP-Pakete mit IP-Optionen schon vor dem Stack verwerfen, MPTCP abschalten, wo es niemand braucht, und Verbindungen aus dem Internet auf wenigen Proxy-Knoten annehmen. seccomp, Capabilities und Pod Security helfen gegen diesen Mechanismus nicht.

Geteilte IP-Optionen im TCP-Handshake

Ein IPv4-Header ist normalerweise 20 Byte lang. Das Feld IHL gibt seine Länge in 32-Bit-Worten an, der Mindestwert 5 entspricht genau diesen 20 Byte, und alles darüber sind IP-Optionen nach RFC 791. Zwei davon spielen hier eine Rolle: Record Route, bei der Router ihre Adresse in das Paket schreiben, und Timestamp, die zusätzlich Zeitstempel sammelt. Im heutigen Internet sind solche Optionen selten. Der Linux-Kernel unterstützt sie aber weiterhin, und wenn ein SYN sie trägt, speichert er sie, um sie in seiner Antwort passend zurückzugeben.

Den Handshake verwaltet der Kernel in zwei Stufen. Trifft ein SYN auf einen lauschenden Socket, legt er einen schlanken Request-Socket an, hinterlegt die Optionen dort im Feld ireq_opt und schickt das SYNACK. Seit Commit 079096f103fa aus Linux 4.4 stehen diese Request-Sockets direkt in der zentralen Hashtabelle für Verbindungen, damit der Kernel eingehende Pakete ohne Umweg über den Listener zuordnen und auf mehreren CPUs parallel verarbeiten kann. Kommt das abschließende ACK, erzeugt tcp_v4_syn_recv_sock() den eigentlichen Verbindungs-Socket, im Kernel-Jargon das Child.

Genau hier lag der Fehler. Das Child übernimmt die Optionen des Request-Sockets in sein Feld inet_opt, ohne sie zu kopieren, und beide zeigen danach auf denselben Speicher. Trifft zur selben Zeit eine Wiederholung des ursprünglichen SYN ein, kann ein anderer Prozessorkern den noch vorhandenen Request-Socket finden und ein weiteres SYNACK bauen, wobei ip_options_build() die gespeicherten Optionen liest. Wird das Child in diesem Moment abgebaut, gibt inet_sock_destruct() die Optionen mit kfree() frei, und der SYNACK-Pfad liest Speicher, den der Allokator womöglich längst einem anderen Objekt gegeben hat. Ein Use-after-free, den ein Angreifer aus der Ferne beliebig oft anstoßen kann, ist ein klassischer Ausgangspunkt für Speicherkorruption.

Ein zweiter, schmalerer Weg führt über die Migration von Request-Sockets. Ist net.ipv4.tcp_migrate_req auf 1 gesetzt oder hängt ein BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE am Listener, reicht der Kernel halb offene Verbindungen an einen anderen Listener derselben Reuseport-Gruppe weiter, und der Klon teilt sich den Optionszeiger mit dem alten Request-Socket. Beides ist ab Werk aus. IPv6 ist vom Hauptpfad nicht betroffen, weil tcp_v6_syn_recv_sock() die Optionen kopiert. Den IPv6-Fall der Migration will das Kernel-Team laut Commit-Nachricht gesondert beheben.

Warum das Design den Fehler begünstigt, zeigt ein Blick auf RCU. Der Kernel liest viele Strukturen im Netzwerkpfad ohne Sperre, geschützt nur durch Read-Copy-Update. Ein Leser markiert dabei einen kurzen kritischen Abschnitt, und wer ein Objekt ersetzt, gibt das alte erst frei, wenn alle Leser, die es noch sehen konnten, diesen Abschnitt verlassen haben. Die übrigen Stellen, an denen inet_opt ersetzt wird, halten sich laut Commit-Nachricht bereits an diese Regel. Nur das endgültige Freigeben beim Abbau des Sockets tat es nicht, und ein sperrfrei lesender Pfad neben einem sofort freigebenden Pfad ist genau die Kombination, die RCU verhindern soll.

Was der Fix-Commit ändert

Der Fix-Commit e3f33b0a1d89 von Eric Dumazet, gemeldet von Xinyang Ge und upstream in Linux 7.3-rc7 enthalten, ist bemerkenswert klein. In inet_sock_destruct() in net/ipv4/af_inet.c und in tcp_v4_reqsk_destructor() in net/ipv4/tcp_ipv4.c ersetzt er das direkte kfree() durch kfree_rcu(). Der Speicher der Optionen wird damit erst nach einer RCU-Gnadenfrist zurückgegeben, also wenn kein Leser mehr im kritischen Abschnitt stecken kann, der den Zeiger noch gesehen hat. An der Logik des Handshakes ändert sich nichts, und auch das Teilen des Zeigers bleibt bestehen.

Daraus lässt sich einiges über die Ursache ablesen. Es ging nie um falsch geparste Optionen oder eine fehlende Längenprüfung, denn der Code las die richtigen Daten, nur zu spät. Die beiden Fixes-Zeilen verweisen auf Optimierungen, die Request-Sockets in die Hashtabelle verlegt und ihre Migration ermöglicht haben. Beide haben den Handshake parallel gemacht, und die Lebensdauer der Optionen wurde dabei nicht mitgedacht. Dass der Fehler rund zehn Jahre unbemerkt blieb, passt zu diesem Bild, weil ein verlorenes Wettrennen im Normalbetrieb keine Spuren hinterlässt.

Vom SYN-Paket zur root-Shell

Für den Hauptpfad braucht ein Angreifer keine besondere Konfiguration auf dem Ziel. Es genügen ein erreichbarer IPv4-TCP-Listener und die Möglichkeit, SYN-Pakete mit IP-Optionen zu schicken, und daraus ergibt sich die Bewertung von 9.8 durch das CNA des Kernels. Amazon setzt die Angriffskomplexität auf hoch und kommt auf 8.1, und das halte ich für die realistischere Einordnung, weil der Angreifer ein enges Zeitfenster zwischen zwei Prozessorkernen treffen muss. Red Hat bewertet vorläufig nur die Verfügbarkeit, also einen Absturz, und landet bei 5.9.

Wie aus dem Wettrennen mehr wird, beschreibt Anthropic in seinem Bericht vom 27. Oktober nur in groben Zügen. Die Kette hat zwei Stufen. Zuerst gewinnt der Angreifer das Rennen so, dass der Kernel zu viel liest und in einer Antwort einen Kernel-Zeiger preisgibt, womit KASLR, die zufällige Anordnung des Kernels im Speicher, ausgehebelt ist. Danach überschreibt er einen Callback-Zeiger und lenkt die Ausführung auf eine Kette vorhandener Kernel-Funktionen, die einen Befehl als root startet. Im Versuch dauerte das Leck rund 48 Minuten, die Ausführung weitere fünf. Ein verlorenes Rennen lässt laut Anthropic nur den Handshake scheitern, ohne das System abstürzen zu lassen, der Angreifer kann es also beliebig oft wiederholen.

Die gezeigte Kette zielt auf Server mit einem Multipath-TCP-Listener. Warum MPTCP dafür nötig ist, erklärt Anthropic nicht, und Code, Offsets oder die getestete Kernel-Version hat das Unternehmen nicht veröffentlicht. Der Fehler selbst liegt im gewöhnlichen IPv4-Pfad. TuxCare gibt das Go-Security-Team mit der Einschätzung wieder, dass auch Systeme ohne MPTCP-Listener für ähnliche Angriffe anfällig sein können. MPTCP abzuschalten senkt also das Risiko der bekannten Kette, schließt die Lücke aber nicht.

Ob ein Server ab Werk einen MPTCP-Listener hat, entscheidet sich an zwei Stellen. Der Kernel erlaubt MPTCP-Sockets, wenn net.mptcp.enabled auf 1 steht, und das ist laut Kernel-Doku die Voreinstellung, während die RHEL-Familie den Wert auf 0 setzt. Zusätzlich muss eine Anwendung ausdrücklich einen MPTCP-Socket öffnen, und genau das tun Go-Programme seit Go 1.24 von selbst. ListenConfig nutzt MPTCP auf Linux standardmäßig, gesteuert über die GODEBUG-Einstellung multipathtcp, deren Standardwert 2 MPTCP für Listener einschaltet. Traefik, Caddy und damit FrankenPHP, CrowdSec, k3s und viele Kubernetes-Komponenten sind in Go geschrieben. Ob ein bestimmter Dienst die Voreinstellung übernimmt, hängt von seiner Go-Version und seinem Code ab, deshalb würde ich es auf dem eigenen Host nachsehen statt es anzunehmen.

Für Kubernetes kommt ein Detail hinzu, das leicht übersehen wird. net.mptcp.enabled gilt pro Netzwerk-Namespace, und der Kernel setzt den Wert für jeden neuen Namespace in net/mptcp/ctrl.c auf 1, unabhängig vom Wert auf dem Host. Ein Pod mit eigenem Netzwerk-Namespace kann also MPTCP-Listener öffnen, auch wenn der Host den Schalter auf 0 stehen hat. Knoten mit vielen Container-Workloads sind damit eher stärker exponiert als ein einzelner Server.

Wirklich betroffen sind Maschinen, deren Kernel TCP-Verbindungen aus nicht vertrauenswürdigen Netzen selbst annimmt: Ingress- und Edge-Knoten, Hosts mit öffentlicher IP, Bastion-Hosts mit offenem SSH-Port und Datenbanken, die von außen erreichbar sind. Ein Backend hinter einem Reverse Proxy, der TCP terminiert, sieht das SYN des Angreifers nie, weil der Proxy eine eigene Verbindung aufbaut und dabei keine fremden IP-Optionen übernimmt. Das leite ich aus dem Mechanismus ab. Wer einen Kernel aus der betroffenen Liste betreibt, aber nur interne Verbindungen annimmt, hat ein deutlich kleineres Risiko, solange niemand bereits im internen Netz sitzt. Auf Knoten mit mehreren Mandanten gilt diese Entwarnung allerdings nicht, denn dort teilen sich fremde Pods den Kernel.

Bis zum 31. Oktober nennt keine der geprüften Quellen einen öffentlichen Exploit oder eine unabhängige Reproduktion. Angriffe in freier Wildbahn sind nicht bekannt, und die Lücke steht nicht im CISA-KEV-Katalog. EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 30. Oktober auf 0,45 Prozent. Diese Zahl unterschätzt die Lage aus meiner Sicht, weil ein Hersteller den Weg zur root-Shell bereits beschrieben hat und Kernel-Patches sich gut vergleichen lassen.

Gepatchte Kernel und der Weg dorthin

Der einzige vollständige Fix ist ein Kernel mit Commit e3f33b0a1d89 oder seinem Backport. Upstream ist er in den stabilen Linien 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 und 7.2.10 enthalten sowie in Linux 7.3. Ein Verhaltenswechsel ist damit nicht verbunden, denn der Fix verzögert nur das Freigeben einiger Bytes um eine Gnadenfrist. Wirksam wird er aber erst nach einem Neustart, und genau daran scheitert es in der Praxis am häufigsten.

Für Amazon Linux meldet das Security Center am 30. Oktober jedes Kernel-Paket als gefixt:

• Amazon Linux 2023, kernel6.18: ALAS2023-2026-3251 vom 24. Oktober
• Amazon Linux 2023, kernel6.12: ALAS2023-2026-3335 vom 29. Oktober
• Amazon Linux 2023, kernel: ALAS2023-2026-3365 vom 30. Oktober
• Amazon Linux 2, kernel: ALAS2-2026-4065 vom 30. Oktober
• Amazon Linux 2, Kernel-5.4, Kernel-5.10 und Kernel-5.15 aus den Extras: ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137 und ALAS2KERNEL-5.15-2026-120 vom 30. Oktober

Bei Amazon Linux 2023 lauert eine Stolperfalle. Die Paketquellen sind laut AWS-Doku auf die Version eingefroren, mit der das AMI gebaut wurde, und ein einfaches Update holt den neuen Kernel deshalb nicht unbedingt. Mit sudo dnf check-release-update siehst du, welche Release-Versionen verfügbar sind, und mit sudo dnf upgrade --releasever=<version> wechselst du auf eine davon. Wer seine Instanzen ohnehin aus Images neu baut, tauscht stattdessen das AMI.

Debian hat die Fixes über DLA-4841-1 als 6.1.190-1 für Bookworm, über DSA-6568-1 als 6.12.113-1 für Trixie und über DLA-4850-1 als 6.12.113-1~deb12u1 im Paket linux-6.12 für Bookworm ausgeliefert. Container-Images auf Basis von Wolfi, Alpine oder Debian enthalten keinen Kernel, denn jeder Container nutzt den Kernel seines Hosts. Ein neu gebautes Image ändert an dieser Lücke also nichts. Anders ist es bei Kata Containers, die mit einem eigenen Gast-Kernel laufen, der dann ebenfalls aktualisiert werden muss.

In Kubernetes-Clustern heißt das konkret: Knoten nacheinander leeren, aktualisieren und neu starten oder gleich durch Knoten aus einem frischen Image ersetzen. Prüfe danach mit uname -r, ob wirklich der neue Kernel läuft, denn ein installiertes Paket ohne Neustart schützt nicht.

Härtung, die über den Patch hinaus wirkt

Zuerst eine Einordnung. Der Angriff braucht weder Code im Container noch einen ungewöhnlichen Systemaufruf, er kommt als Netzwerkpaket von außen und trifft den Kernel, bevor überhaupt ein Prozess beteiligt ist. Wirksam ist deshalb alles, was verhindert, dass ein SYN mit IP-Optionen den TCP-Stack erreicht, was die Zahl der Kernel verkleinert, die fremde Verbindungen annehmen, oder was den Code-Pfad der gezeigten Kette abschaltet. Maßnahmen, die nur den Container einschränken, greifen hier ins Leere.

TCP-Pakete mit IP-Optionen vor dem Stack verwerfen

Der Fehler setzt voraus, dass ein SYN IP-Optionen trägt, denn nur dann hat der Request-Socket überhaupt etwas in ireq_opt stehen. Ein Paketfilter, der IPv4-TCP-Pakete mit einem Header länger als 20 Byte verwirft, entzieht dem Angriff deshalb die Grundlage. AlmaLinux veröffentlicht dafür eine nftables-Regel, die in einer eigenen Tabelle in der Prerouting-Kette mit Priorität -300 jedes Paket mit meta l4proto tcp ip hdrlength > 5 zählt und verwirft. Die Priorität sorgt dafür, dass die Regel greift, bevor Connection Tracking und die übrigen Filter das Paket sehen.

Die Grenzen solltest du kennen. Die Regel überlebt laut AlmaLinux keinen Neustart, wer sie behalten will, muss sie in die eigene Firewall-Konfiguration übernehmen. Sie bricht Netze, die auf CIPSO- oder NetLabel-Kennzeichnung angewiesen sind, weil diese als IP-Option übertragen wird. Und Verkehr zwischen Containern auf demselben Host kann an ihr vorbeilaufen. Bevor du verwirfst, würde ich die Regel zunächst ohne drop nur mit counter laden und eine Weile beobachten, ob legitimer Verkehr überhaupt IP-Optionen nutzt. Das ist meine eigene Empfehlung und keine Vorgabe von AlmaLinux. IPv6 musst du für den Hauptpfad nicht filtern.

MPTCP abschalten, wo es niemand braucht

Die gezeigte Kette braucht einen MPTCP-Listener. Mit net.mptcp.enabled = 0 in einer Datei unter /etc/sysctl.d/ und sysctl -w net.mptcp.enabled=0 lässt der Host keine neuen MPTCP-Sockets mehr zu. Bestehende Listener laufen allerdings weiter, bis du die betroffenen Dienste neu startest, und mit ss -lnMp siehst du, welche das sind. Weil der Schalter pro Netzwerk-Namespace gilt und jeder neue Namespace mit 1 beginnt, erreicht der Host-Wert deine Pods nicht. Für Go-Dienste ist GODEBUG=multipathtcp=0 in der Umgebung des Containers deshalb der direktere Hebel, denn damit verhält sich der Dienst wieder wie vor Go 1.24.

Den Wert im Pod selbst zu setzen, ist in Kubernetes umständlicher. net.mptcp.enabled gehört nicht zu den sicheren Sysctls, die ein Pod über securityContext.sysctls ohne Weiteres setzen darf. Der Kubelet muss ihn dafür über --allowed-unsafe-sysctls auf jedem Knoten freigeben, und Pods mit hostNetwork: true können net.*-Sysctls gar nicht setzen. Ich halte die Umgebungsvariable daher für den praktikableren Weg. Beide Maßnahmen verkleinern nur die Angriffsfläche der bekannten Kette, sie schließen die Lücke im IPv4-Pfad nicht.

Fremde Verbindungen nur an wenigen Stellen annehmen

Je weniger Kernel TCP-Verbindungen aus dem Internet selbst annehmen, desto kleiner ist die Menge an Maschinen, die bei einer solchen Lücke sofort gepatcht werden müssen. Ein Reverse Proxy oder ein Load Balancer, der TCP terminiert, nimmt das SYN des Angreifers an und baut zum Backend eine eigene Verbindung auf, die Backends sehen fremde IP-Optionen also nicht. Für die Verwaltung von EC2-Instanzen braucht der Session Manager von AWS Systems Manager keinen offenen eingehenden Port, ein öffentlich erreichbarer SSH-Port fällt damit weg. In Kubernetes gehören NodePort, hostPort und hostNetwork auf den Prüfstand, und NetworkPolicies mit Ingress-Regeln begrenzen, wer einen Pod überhaupt erreichen kann.

Diese Maßnahme verschiebt das Risiko, statt es aufzulösen. Die Proxy-Knoten nehmen weiterhin fremde SYNs an und müssen als Erste gepatcht werden, auf ihnen lohnt auch der Paketfilter aus dem ersten Abschnitt. Ein Load Balancer, der Pakete auf Schicht 4 nur weiterleitet, terminiert keine Verbindung, und dann sieht das Backend das SYN doch. Ob ein AWS Network Load Balancer IP-Optionen an seine Ziele durchreicht, dokumentiert AWS nicht. Ich würde Ziele hinter einem solchen Load Balancer deshalb so behandeln, als nähmen sie die Verbindungen selbst an. NetworkPolicies filtern nach Adressen und Ports, nicht nach IP-Optionen, sie helfen also nur, wenn der Angreifer gar nicht erst durchkommt.

Mandanten-Workloads vom Host-Kernel trennen

Teilen sich mehrere Mandanten einen Knoten, verarbeitet derselbe Kernel die Handshakes aller Pods. gVisor bringt mit netstack einen eigenen Netzwerk-Stack mit, den laut Doku vollständig der Sentry behandelt und der damit vom Netzwerk-Stack des Hosts getrennt ist. Ein Listener in einem gVisor-Pod läuft deshalb nicht durch den TCP-Handshake des Host-Kernels, was ich aus dieser Architektur ableite. Im Passthrough-Modus mit --network=host entfällt dieser Schutz. Kata Containers trennen über eine eigene virtuelle Maschine mit Gast-Kernel, der für diese Lücke aber genauso gepatcht sein muss. Beides wählst du in Kubernetes über eine RuntimeClass. Der Preis sind Leistung und Kompatibilität, sodass sich dieser Weg vor allem für fremden oder wenig vertrauenswürdigen Code lohnt.

Kernel-Updates als Routine statt als Projekt

Diese Lücke zeigt, dass ein Kernel-Patch erst mit dem Neustart wirkt. Werkzeuge wie kured, der Kubernetes Reboot Daemon, leeren Knoten nach einem Update geordnet und starten sie nacheinander neu. Wer seine Knoten aus Images baut, rollt stattdessen neue AMIs oder Knoten-Images aus und lässt alte Knoten auslaufen. Entscheidend ist, dass dieser Ablauf regelmäßig läuft, damit er bei einer kritischen Lücke keine Sonderaktion mehr ist.

Was hier nicht hilft

Viele bewährte Härtungen bleiben richtig, sind gegen diesen Mechanismus aber wirkungslos. seccomp mit RuntimeDefault oder einem eigenen Profil filtert Systemaufrufe von Prozessen, und hier ruft niemand etwas auf, das Paket landet direkt im Netzwerk-Stack. Entzogene Capabilities, runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem und der Pod Security Standard „restricted“ begrenzen, was ein Prozess im Container tun darf. Der Angreifer braucht aber gar keinen Prozess, und hat er die Kette einmal durchlaufen, führt der Kernel seinen Befehl außerhalb jedes Containers aus.

User Namespaces ändern nichts an diesem Bild, weil sie Benutzerkennungen abbilden, den Kernel aber nicht wechseln. Ein minimales Base-Image ohne Shell schützt nicht, denn der Befehl des Angreifers läuft auf dem Host und nicht im Image. Auch ein CVE-Gate für Container-Images schlägt nicht an, weil der verwundbare Code im Kernel des Knotens steckt und in keinem Image vorkommt. Ein Scanner, der nur Images prüft, meldet hier also grünes Licht, während der Knoten offen ist.

Mehr zu Netzwerkregeln, Knoten-Härtung und Update-Abläufen findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Erkennung und Prüfung

Den ersten Hinweis auf eine Verwundbarkeit liefert uname -r auf jedem Host und jedem Knoten, verglichen mit den Fix-Versionen deiner Distribution. Bei Amazon Linux liefert rpm -q kernel beziehungsweise rpm -q kernel6.12 oder kernel6.18 die installierte Version, maßgeblich bleibt aber der laufende Kernel. Danach lohnt der Blick auf die Exposition. sysctl net.mptcp.enabled zeigt den Wert des Host-Namespace, ss -lnMp die MPTCP-Listener. Weil Pods eigene Netzwerk-Namespaces haben, musst du ss dort im jeweiligen Namespace ausführen, etwa über nsenter mit der PID eines Container-Prozesses. Prüfe außerdem, ob net.ipv4.tcp_migrate_req auf 0 steht und ob BPF-Programme vom Typ Reuseport geladen sind, die den zweiten Pfad öffnen würden.

Schwieriger ist die Frage, ob jemand es bereits versucht hat. Hersteller und Anthropic nennen keine Indikatoren. Aus dem Mechanismus leite ich zwei Signale ab. Ein Angreifer muss viele SYNs mit IP-Optionen schicken, und legt man Anthropics Zeitangaben zugrunde, zieht sich das eher über eine Stunde als über ein paar Sekunden. Der Zähler der nftables-Regel aus dem Härtungsabschnitt macht genau das sichtbar, auch im reinen Zählmodus. Außerdem kann ein misslungener Versuch den Kernel abstürzen lassen, was Amazon als wahrscheinlichste Folge nennt. Kernel-Oops oder Abstürze mit ip_options_build oder inet_sock_destruct im Stacktrace gehören deshalb genau angesehen.

Bei einem Verdacht gilt die übliche Regel für Kernel-Kompromittierungen. Wer Code als root im Kernel ausführen konnte, kann Spuren verwischen und sich festsetzen, ein Aufräumen im laufenden System ist daher nicht vertrauenswürdig. Nimm den Host vom Netz oder leere und sperre den Knoten, sichere Speicherabbild und Logs, wenn du das forensisch brauchst, und baue die Maschine aus einem gepatchten Image neu auf. Danach rotierst du alles, was auf dem Host lag oder von ihm erreichbar war: Kubelet-Zugangsdaten, Service-Account-Tokens der Pods auf diesem Knoten und die Sitzungen der Instanzrolle.

Betreiberempfehlung

Akut handeln solltest du bei allen Maschinen, deren Kernel TCP-Verbindungen aus dem Internet oder von fremden Mandanten selbst annimmt: Ingress-Knoten, Proxys, Hosts mit öffentlicher IP und Kubernetes-Knoten mit mehreren Mandanten. Spiele dort den gepatchten Kernel ein und starte neu. Bis das erledigt ist, lade den Paketfilter für IP-Optionen und setze für Go-Dienste GODEBUG=multipathtcp=0, sofern du MPTCP nicht bewusst nutzt.

Beobachten genügt, wenn ein Host nur Verbindungen aus einem vertrauenswürdigen internen Netz annimmt, etwa ein Backend hinter einem terminierenden Proxy oder eine Datenbank ohne Zugang von außen. Das Update gehört trotzdem in das nächste reguläre Wartungsfenster, denn ein Angreifer, der bereits im internen Netz sitzt, findet hier einen bequemen Weg zu root.

Am Ende bleibt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert, und bei Kernel-Lücken heißt das auch, den Neustart zu automatisieren. Wenn Renovate oder Dependabot neue AMI-Versionen, Knoten-Images und Helm-Charts als Merge Request vorschlagen und die Pipeline sie gegen Staging testet, ist ein Kernel-Fix wie dieser eine Sache von Stunden statt Wochen. Eine Karenzzeit für Routine-Updates schützt vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Falls ein neuer Kernel Treiber oder Workloads bricht, fällt das in Staging auf und nicht auf dem Ingress-Knoten in Produktion. Wer Kernel dagegen von Hand aktualisiert, hat in der Urlaubszeit schnell vier Wochen offene Knoten und danach ein Sammel-Update, bei dem Kernel, Container-Runtime und Charts gleichzeitig wechseln.

Fazit

CVE-2026-98432 ist kein Parser-Fehler und keine vergessene Längenprüfung. Der Kernel las die richtigen Daten, aber zu einem Zeitpunkt, an dem sie ihm nicht mehr gehörten, weil zwei Objekte sich einen Speicherbereich teilten und nur eines davon RCU ernst nahm. Solche Fehler entstehen, wenn Code parallelisiert wird und die Lebensdauer geteilter Daten nicht mitwandert. Für Betreiber steckt die übertragbare Lehre an anderer Stelle. Die Angriffsfläche eines Servers hängt an Voreinstellungen, die sich ohne eigenes Zutun ändern, wie hier durch Go 1.24, das MPTCP-Listener still eingeschaltet hat. Wer nur offene Ports zählt und nicht prüft, welche Protokolle der Kernel dahinter annimmt, unterschätzt seine Exposition. Ein Inventar der Listener samt Protokoll und ein Paketfilter, der Ungewöhnliches gar nicht erst durchlässt, sind deshalb mehr wert als jede einzelne Patch-Runde.

Quellen

• Debian Security Tracker: CVE-2026-98432
• kernel.org: ChangeLog 6.18.56 mit dem Backport von e3f33b0a1d89
• OpenCVE: CVE-2026-98432 (CVSS des Kernel-CNA und von Red Hat)
• Amazon Linux Security Center: CVE-2026-98432
• Anthropic: Discovering vulnerabilities with Claude
• AlmaLinux: CVE-2026-98432, Patched kernels available in testing
• TuxCare: CVE-2026-98432 Linux Kernel TCP Flaw
• Red Hat Bugzilla 2553390
• Kernel-Doku: MPTCP Sysfs variables
• Linux-Quelltext: net/mptcp/ctrl.c
• Kernel-Doku: What is RCU?
• RFC 791: Internet Protocol
• Go: GODEBUG-Einstellungen (multipathtcp)
• Go 1.24 Release Notes
• Kubernetes Docs: Using sysctls in a Kubernetes Cluster
• AWS: Deterministic upgrades in Amazon Linux 2023
• gVisor: Networking
• FIRST EPSS: CVE-2026-98432