Linux-Kernel: Use-after-free im IPv4-TCP-Handshake (CVE-2026-98432)

The Hacker News berichtet über diese Lücke unter dem Titel "Linux Kernel TCP Flaw with 9.8 CVSS", Aikido am 02.11.2026 unter "Critical Linux kernel TCP vulnerability can allow remote code execution". Anthropics Exploit greift einen Server mit MPTCP-Listener an, der Fehler selbst steckt aber im normalen IPv4-TCP-Code, nicht in MPTCP. Deshalb liegt die Beschreibung unter tcp-handshake/. Dazu gehört auch das verwandte IPv6-Problem mit CALIPSO-Optionen, das einen eigenen Patch bekommt.

Im Aikido-Artikel steht in einer Zwischenüberschrift "CVE-2025-98432". Das ist ein Tippfehler, gemeint ist CVE-2026-98432. Eine eigene CVE für den IPv6-Teil gibt es bisher nicht.

Worum es geht

Beim TCP-Handshake übergibt der Kernel die IP-Optionen der Verbindungsanfrage (ireq->ireq_opt) an den neuen Socket, ohne sie zu kopieren (tcp_v4_syn_recv_sock()). Verarbeitet eine andere CPU gleichzeitig ein wiederholtes SYN für dieselbe Anfrage, baut sie daraus ein SYNACK. Wird der neue Socket in diesem Moment freigegeben, liest ip_options_build() freigegebenen Speicher (Use-after-free). Eine ähnliche Race gibt es bei der Migration von Request-Sockets, wenn net.ipv4.tcp_migrate_req=1 gesetzt ist oder ein BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE läuft.

• Eingeführt mit Commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table", Eric Dumazet, 02.10.2015) in Linux 4.4. Seitdem verarbeitet der Kernel Request-Sockets ohne Listener-Lock.
• Der Fix gibt die Optionen erst nach einer RCU-Grace-Period frei (kfree_rcu() in inet_sock_destruct() und tcp_v4_reqsk_destructor()). Upstream-Commit e3f33b0a1d89 ("ipv4: free inet_opt and ireq_opt after an RCU grace period") vom 05.10.2026. Die CVE ist seit 15.10.2026 veröffentlicht.
• IPv6 ist vom Hauptfehler nicht betroffen, weil tcp_v6_syn_recv_sock() die Optionen kopiert. Das Migrationsproblem gibt es dort ebenfalls, aber nur mit CALIPSO-Optionen. Das soll ein eigener Patch beheben.
• Ausgelöst wird der Fehler laut Kernel-CVE-Team mit einem SYN, das die IPv4-Optionen Record Route oder Timestamp trägt, und einem wiederholten SYN, um die Race zu gewinnen. Ohne IP-Optionen im SYN gibt es keine Optionen, die freigegeben werden könnten.
• Mögliche Folgen: Kernel-Speicher geht an den Angreifer zurück, Kernel-Speicher wird überschrieben, das System stürzt ab.
• Gefunden hat die Lücke laut The Hacker News Xinyang Ge von Anthropic. Der Kernel-Fix nennt einen Anthropic-Forscher als Melder.

Bewertung

Der einzige Unterschied zwischen 9.8 und 8.1 ist die Angriffskomplexität. Das Kernel-CVE-Team setzt sie auf niedrig, weil der Angreifer beide Seiten der Race selbst auslöst. Red Hat setzt sie auf hoch und erwartet vor allem Abstürze, Speicherkorruption hält Red Hat nur für theoretisch möglich. Auf der CVE-Seite führt Red Hat inzwischen 5.9, die VEX-Datei vom 30.10. noch 8.1.

Ausnutzung

• Anthropic hat einen Exploit gebaut, der ohne Login und ohne Zutun eines Nutzers Root-Rechte auf einem Linux-Server mit MPTCP-Listener erreicht. Stufe 1 nutzt die Race, damit der Kernel zusätzliche Bytes an den Angreifer schickt. Enthält eine Antwort einen Kernel-Pointer, ist KASLR ausgehebelt. Stufe 2 nutzt denselben Fehler für einen Buffer-Overflow, überschreibt einen Callback-Pointer und springt in eine vorher im Kernel abgelegte Payload, die einen Shell-Befehl als root ausführt.
• Dauer im Test: 48 Minuten bis zum Kernel-Pointer, weitere 5 Minuten bis zur Codeausführung. Eine verlorene Race lässt nur den Handshake scheitern, der Angreifer kann also beliebig oft wiederholen.
• Exploit-Code, Kernel-Version und Testkonfiguration hat Anthropic nicht veröffentlicht. Warum der MPTCP-Listener nötig ist, sagt der Beitrag nicht. Das Kernel-Team von CloudLinux konnte den Exploit laut Aikido nicht nachstellen.
• Weder der CVE-Eintrag noch der Kernel-Fix erwähnen MPTCP. Das Go Security Team hält deshalb auch Systeme ohne MPTCP-Listener für möglicherweise angreifbar.
• MPTCP-Listener sind häufiger als gedacht: Seit Go 1.24 fordern Go-Programme für ihre Listen-Sockets standardmäßig MPTCP an, wenn der Kernel es erlaubt. Ein Go-Server wird so zum MPTCP-Listener, ohne dass jemand das bewusst eingestellt hat. AlmaLinux und CloudLinux liefern MPTCP standardmäßig abgeschaltet aus.
• Aktive Angriffe sind nicht bekannt. CISA führt die Lücke nicht im KEV-Katalog (Version 2026.10.29). Der EPSS-Wert liegt am 29.10. bei 0,39 % (Perzentil 32,8).

Welche Kernel betroffen sind

Betroffen ist jeder Kernel ab 4.4 ohne den Fix, auf dem ein Angreifer einen IPv4-TCP-Port erreicht. Gefixt sind diese stabilen Versionen:

Kernel vor 4.4 (z. B. 3.10, 3.13, 4.1) enthalten den verursachenden Commit nicht. Distributionskernel mit vielen Backports können davon abweichen, deshalb zählt bei Debian, Ubuntu und Red Hat die Aussage des Herstellers, nicht die Versionsnummer.

Was vor dem Host steht, ändert die Lage nur, wenn es TCP selbst terminiert:

• Ein Reverse Proxy (nginx, HAProxy) auf demselben Linux-Host schützt nicht. Den Handshake macht der Kernel der Maschine, die die Verbindung annimmt.
• Bei Containern zählt der Kernel des Nodes, auf dem sie laufen.
• Ein separater Load Balancer oder Managed Service, der TCP terminiert, hält Pakete aus dem Internet vom Kernel fern. Die Hosts dahinter brauchen den Fix trotzdem.

Debian

Debian 11 bullseye fehlt im Tracker, weil Debian LTS dafür am 31.08.2026 geendet hat. Der Kernel 5.10 liegt im betroffenen Bereich, einen Fix von Debian gibt es nicht mehr. Wer Freexians ELTS nutzt, muss dort nachsehen. Dasselbe gilt für buster mit 4.19.

Die gefixten Pakete in bookworm und trixie liegen bisher nur in *-security. Der Point-Release-Stand (6.1.176-1, 6.12.107-1) ist noch verwundbar.

Ubuntu

Ubuntu stuft die Lücke als High ein (CVSS 9.8). Gefixte Kernel gibt es am 29.10. noch für kein Release.

Die Cloud-Kernel (linux-aws, linux-azure, linux-gcp, linux-oracle), FIPS-, Realtime-, Lowlatency- und HWE-Kernel haben eigene Zeilen. In 22.04 bis 26.10 sind die meisten in Arbeit, einzelne wie linux-gcp in 24.04, linux-hwe-6.17 und linux-hwe-7.0 in 24.04 oder linux-nvidia noch als verwundbar ohne Fix geführt. Den genauen Stand pro Paket zeigt die Ubuntu-CVE-Seite.

Red Hat

Red Hat stuft die Lücke als Important ein (CVSS 8.1). Stand VEX-Datei Version 3 vom 30.10.2026:

Betroffen sind jeweils alle Kernel-Varianten, auch kernel-rt und kernel-64k. Eine Mitigation nennt Red Hat nicht: Keine verfügbare Option erfülle die Kriterien einfache Umsetzung, breite Anwendbarkeit und Stabilität.

CentOS

CentOS hat keine eigenen Advisories. Die Kernel kommen aus den RHEL-Quellen, deshalb gilt die Red-Hat-Bewertung des passenden RHEL-Release.

CentOS Linux 7.9.2009

Nach Red Hats Aussage nicht betroffen, solange der Standard-Kernel läuft.

• CentOS 7.9.2009 läuft mit kernel-3.10.0-1160.*.el7 (Basis-Build mit RHEL 7.9 vom 29.09.2020, auf Grundlage von Linux 3.10 aus 2013). Das ist derselbe Kernel wie in RHEL 7, und Red Hat führt RHEL 7 mit vulnerable_code_not_present.
• Der verursachende Commit kam erst mit Linux 4.4. Nach meiner Einschätzung hat Red Hat den Umbau auf Request-Sockets ohne Listener-Lock nie in den 3.10-Kernel zurückportiert, das passt zu "Code nicht vorhanden". Eine Begründung nennt Red Hat nicht.
• MPTCP gibt es im RHEL-7-Kernel nicht. Upstream ist es seit Linux 5.6 enthalten, in RHEL erst ab 8.3.
• Wichtige Ausnahme: Läuft auf CentOS 7 ein fremder Kernel, gilt diese Aussage nicht. Das betrifft vor allem kernel-lt und kernel-ml von ELRepo, selbst gebaute Kernel und Kernel von Hosting-Anbietern. Liegt dessen Version bei 4.4 oder höher und ohne Fix, ist das System betroffen.
• CentOS Linux 7 ist seit 30.06.2024 End of Life. Für die Lücke spielt das keine Rolle, für alle anderen Kernel-Lücken seitdem schon.

CentOS Linux 8

Betroffen. Der Kernel 4.18 entspricht RHEL 8, und RHEL 8 ist betroffen. CentOS Linux 8 ist seit 31.12.2021 End of Life, einen Fix wird es nicht geben.

CentOS Stream 9 und 10

Betroffen, bis ein Kernel mit dem Fix erscheint. Stream ist der Entwicklungszweig von RHEL 9 und 10, eine eigene Bewertung gibt es nicht. Ob der installierte Kernel den Fix enthält, zeigt das Changelog (siehe unten).

Andere Distributionen (kurz)

Laut The Hacker News und den jeweiligen CVE-Seiten am 29.10.:

• Oracle Linux 7 bis 10 mit UEK: gefixt am 16.10. (ELSA-2026-500397, -500398, -500399).
• Amazon Linux 2 und 2023: laut Aikido (02.11.) gefixte Kernel für die Linien 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 und 6.18. Am 29.10. waren erst kernel6.18 (ALAS2023-2026-3251) und kernel6.12 (ALAS2023-2026-3335) gefixt. Details im Abschnitt AWS.
• SUSE: gefixt in SUSE Linux Micro 6.2 und openSUSE Leap 16.0. SLES 15 SP4 bis SP7, SLES 16.0 und SLE Micro 5.3 bis 5.5 noch offen.

AWS

Laut AWS (zitiert von Aikido, 02.11.) ist ein gefixter Kernel mit Neustart die einzige vollständige Abhilfe. Ein Livepatch behebt die Lücke ebenfalls.

Selbst prüfen

# Laufender Kernel
uname -r

# Ist MPTCP aktiv, gibt es MPTCP-Listener?
sysctl net.mptcp.enabled
ss -Mltn

# Go-Programme ab 1.24 öffnen MPTCP-Listener von selbst. Ist GODEBUG gesetzt?
tr '\0' '\n' < /proc/<PID>/environ | grep GODEBUG

# Request-Socket-Migration (Standard: 0)
sysctl net.ipv4.tcp_migrate_req

# Debian/Ubuntu: installierte Kernel-Pakete
dpkg -l 'linux-image-*' | grep '^ii'

# RHEL, CentOS Stream, Oracle Linux: steht der Fix im Changelog?
rpm -q --changelog kernel-core | grep -i 'free inet_opt and ireq_opt'

Nach dem Kernel-Update muss das System neu starten. Erst wenn uname -r die neue Version zeigt, ist der Fix aktiv. Scanner, die nur installierte Pakete auswerten (z. B. Aikidos VM-Scan), zeigen einen Host schon vor dem Neustart als gefixt an.

Was tun

1. Gefixten Kernel einspielen und neu starten, wo es ihn gibt: Debian bookworm, trixie, forky und sid, Oracle Linux, Amazon Linux 2 und 2023 sowie Teile von SUSE. Zuerst Hosts mit Port ins Internet, auch vergessene VMs und Container-Nodes.
2. Wer selbst Kernel baut: auf eine der gefixten Stable-Versionen aus der Tabelle oben gehen. Das Kernel-CVE-Team rät davon ab, nur den einzelnen Commit zu übernehmen.
3. Für Ubuntu, RHEL 8 bis 10, CentOS Stream und OpenShift gibt es noch keinen Fix. Bis dahin senken die folgenden Maßnahmen das Risiko, beheben den Fehler aber nicht. AWS nennt die Firewall-Regel und das Abschalten von MPTCP als Übergangslösung. Red Hat hält keine der geprüften Maßnahmen für einfach, breit anwendbar und stabil.

Eingehende IPv4-Pakete mit IP-Optionen verwerfen

Der Fehler braucht ein SYN mit IPv4-Optionen (Record Route, Timestamp). Normaler Verkehr nutzt keine IP-Optionen, viele Router verwerfen solche Pakete ohnehin. Ein IPv4-Header ohne Optionen hat die Länge 5 (in 32-Bit-Worten), alles darüber enthält Optionen.

# nftables
nft add rule inet filter input ip hdrlength != 5 drop

# iptables: IHL (untere 4 Bit des ersten Bytes) zwischen 6 und 15
iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Die iptables-Regel ist die von AWS veröffentlichte. Für AWS Network Firewall gibt es eine gleichwertige Stateful-Regel, die strikte Regelreihenfolge braucht. Die Regel muss vor der ersten Regel stehen, die bestehende oder erlaubte Verbindungen annimmt. Auf Hosts, die Pakete weiterleiten (Kubernetes-Nodes, Router), gehört sie zusätzlich in die forward-Chain bzw. FORWARD. Gegen das Migrationsproblem hilft die Regel nur bedingt, das ist aber nur bei tcp_migrate_req=1 oder einem passenden BPF-Programm relevant.

MPTCP abschalten, wo es nicht gebraucht wird

sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' > /etc/sysctl.d/90-disable-mptcp.conf

Danach legt der Kernel keine neuen MPTCP-Sockets mehr an, Anwendungen fallen auf normales TCP zurück. Das nimmt Anthropics gezeigten Angriffsweg weg, behebt aber nicht den Fehler im IPv4-TCP-Code. Ob Server ohne MPTCP genauso angreifbar sind, ist offen.

Wer MPTCP systemweit braucht, kann es für Go-Programme ab 1.24 einzeln abschalten:

GODEBUG=multipathtcp=0

Das Go Security Team nennt das eine schwache Maßnahme: Ein einziger übersehener MPTCP-Listener lässt das System verwundbar. Für Go-Server ohne vorgeschalteten Load Balancer empfiehlt Aikido die Variable trotzdem bis zum Patch.

Host hinter einen separaten Load Balancer stellen

Ein Load Balancer oder Managed Service, der TCP terminiert, bevor Pakete den Kernel erreichen, nimmt den Angriffsweg aus dem Internet weg. Ein Proxy auf demselben Host zählt nicht.

tcp_migrate_req auf 0 lassen

Der Standard ist 0. Wer es auf 1 gesetzt hat, sollte es bis zum Kernel-Update zurücksetzen.

Quellen

• The Hacker News: Linux Kernel TCP Flaw with 9.8 CVSS
• Aikido: Critical Linux kernel TCP vulnerability can allow remote code execution (CVE-2026-98432)
• Kernel-CVE-Team: CVE-2026-98432 (mbox)
• Kernel-Fix e3f33b0a1d89
• CVE.org: CVE-2026-98432
• NVD: CVE-2026-98432
• Anthropic: Discovering vulnerabilities with Claude
• Debian Security Tracker: CVE-2026-98432
• DSA-6568-1 (linux, trixie)
• DLA-4841-1 (linux, bookworm)
• DLA-4850-1 (linux-6.12, bookworm)
• Ubuntu: CVE-2026-98432
• Red Hat: CVE-2026-98432
• Red Hat VEX: cve-2026-98432.json
• Red Hat Bugzilla 2553390
• Oracle Linux: CVE-2026-98432
• Amazon Linux Security Center: CVE-2026-98432
• SUSE: CVE-2026-98432
• FIRST EPSS API: CVE-2026-98432
• CISA KEV-Katalog
• Kernel-Dokumentation: MPTCP