CVE-2026-98432 temporäre Gegenmaßnahme

Dieses Repository enthält Skripte, die IPv4-TCP-Pakete mit IP-Optionen auf einem Linux-Host verwerfen. Auf Hosts ohne SELinux/Smack-NetLabel-CIPSO-Kennzeichnung kann CVE-2026-98432 (ein Use-after-free im IPv4-TCP-Stack des Linux-Kernels) ohne solche Pakete nicht ausgelöst werden. Es handelt sich um eine temporäre Gegenmaßnahme, nicht um eine Fehlerbehebung. Sie wurde nicht gegen einen echten Exploit getestet (es gibt keinen öffentlichen PoC), und kein Anbieter befürwortet sie. Wenn Ihre Distribution bereits einen gepatchten Kernel ausliefert, installieren Sie diesen, und führen Sie revert.sh aus, falls Sie diese Maßnahme angewendet haben. Ist das nicht der Fall, prüfen Sie, ob die Gegenmaßnahme auf Ihren Host anwendbar ist, und wenden Sie sie dann mit den folgenden Schritten an und verifizieren Sie sie (etwa 10 Minuten). Der Autor ist ein einzelner Administrator, kein Anbieter.

Betrifft Sie das

Vergleichen Sie uname -r mit den gepatchten stabilen Versionen: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 (Fix-Commit e3f33b0a1d89d738e2b913dab519226eaf76e15b). Ein Distributions-Kernel kann den Fix unter einer anderen Versionsnummer enthalten, prüfen Sie daher auch den Tracker Ihres Anbieters.
Prüfen Sie auf CIPSO-Kennzeichnung: cat /sys/kernel/security/lsm. Wenn SELinux oder Smack aufgeführt ist und Sie NetLabel mit einem CIPSOV4-Mapping verwenden, deckt diese Gegenmaßnahme diesen Pfad nicht ab.
Prüfen Sie die Voraussetzungen: root, systemd und nft. OpenWrt hat einen eigenen Pfad (siehe Dateien). Hosts ohne systemd, außer OpenWrt, werden nicht abgedeckt.

Schweregrad: Die Kernel-CNA vergibt CVSS 9.8. Red Hat, Oracle und SUSE vergeben 8.1, und Amazon vergibt 7.0. Anthropic beschrieb öffentlich einen Remote-Root-Exploit gegen Linux-Server mit einem MPTCP-Listener (2026-10-27). Bis zum 2026-10-29 wurde keine Ausnutzung in freier Wildbahn gemeldet.

Distributionsstatus zum 2026-10-29/30 (eine Momentaufnahme, prüfen Sie daher Ihren Anbieter):

Distribution	Status
Ubuntu (alle unterstützten Releases)	kein gepatchter Kernel
RHEL 8/9/10	kein gepatchter Kernel
Proxmox VE	Das Changelog von `pve-kernel` enthielt am 2026-10-30 keinen Eintrag zu dieser CVE
Debian, Oracle Linux UEK, einige SUSE, einige Amazon Linux	Fixes verfügbar

Anwenden

Führen Sie sudo ./mitigate.sh aus. Das Skript ist idempotent (ein erneuter Lauf lädt das Ruleset neu). Es installiert die unter Dateien aufgeführten Dateien und bricht ab, wenn Sie nicht root sind, wenn nft fehlt oder wenn systemd fehlt.
Vergleichen Sie die Ausgabe mit der folgenden Referenz. Die erste Zeile muss lauten:
```
svc=active enabled=enabled mptcp=0
```
Die beiden Regeln folgen ihm, eine in der Tabelle inet und eine in der Tabelle bridge.
Wenn ein Dienst mit MPTCP lauscht, starte ihn neu. net.mptcp.enabled=0 wirkt sich nur auf neue Sockets aus, daher bleibt ein bereits geöffneter MPTCP-Listener MPTCP, bis sein Dienst neu gestartet wird. Das sysctl gilt pro Netzwerk-Namespace, und mitigate.sh setzt es nur für den Host-Namespace.
Wenn der Host LXC- oder Docker-Container ausführt, fahre mit Containers fort.

Der veröffentlichte Exploit zielte auf MPTCP-Listener. Die Race selbst erfordert kein MPTCP (Schlussfolgerung aus der Beschreibung des Fixes). Ob ein Host ohne MPTCP vollständig kompromittiert werden kann, ist nicht geklärt.

Verify

Das SYN-ACK des Ziels spiegelt die IP-Optionen wider. Ein Client, der selbst diese Mitigation ausführt, verwirft dieses SYN-ACK, sodass check-blocked.py „blocked" meldet, selbst wenn das Ziel nicht mitigiert ist. Auf einem Host gemessen: Nach revert.sh auf dem Ziel gab check-blocked.py von einem mitigierten Client weiterhin ipopt FAIL TimeoutError aus, während verify-synack.sh ipopt synack=5 zeigte.

Wähle ein Tool:

Wenn du einen Client ohne diese Mitigation hast, führe dort python3 check-blocked.py <host> <port> aus (kein Root erforderlich). Es verbindet sich zweimal: zuerst einfach, dann mit einer IPv4-Record-Route-Option, die über die Socket-Option IP_OPTIONS gesetzt wird.
Wenn du das nicht garantieren kannst, führe sudo ./verify-synack.sh <ip> <port> auf einem beliebigen Client aus (Root, tcpdump und python3 werden auf dem Client benötigt). Es sendet ein einfaches SYN und ein SYN mit IP-Optionen von festen Quellports und zählt die SYN-ACKs des Ziels mit tcpdump.

Vergleiche dann die Ausgabe mit der Tabelle für dieses Tool.

check-blocked.py (von einem Client ohne die Mitigation):

Ausgabe	Bedeutung
`plain CONNECTED`	normales TCP funktioniert
`ipopt FAIL TimeoutError`	das SYN mit IP-Optionen wurde wie beabsichtigt verworfen

verify-synack.sh:

Ausgabe	Bedeutung
`plain: CONNECTED synack=N \| ipopt: TimeoutError synack=0`	Ziel ist mitigiert
`ipopt ... synack>=1`	Ziel ist nicht mitigiert (das SYN mit IP-Optionen wurde beantwortet)

Ergebnis auf Kernel-Ebene (ein Proxmox-VE-Host, Kernel 7.0, 2026-10-30): Mit deaktivierter Mitigation lief der verwundbare Codepfad einmal pro Pfad, über WireGuard und LXC zu LXC. Mit aktivierter Mitigation lief das SYN in einen Timeout und der Pfad lief 0-mal. Die Stichprobe umfasst 2 Pfade in 2 Zuständen auf einem Host. Die Tracing-Methode ist in docs/ANALYSIS.md beschrieben (Englisch).

Containers

Der nftables-Zustand gilt pro Netzwerk-Namespace, daher schützen Host-Regeln allein keine Container-Namespaces. Auf LXC-Containern gemessen: Mit nur Host-Regeln konnte ein SYN mit IP-Optionen aus einem Container an dessen eigenes 127.0.0.1 oder dessen eigene IP eine Verbindung herstellen. Container teilen sich den Host-Kernel, sodass Code in jedem Container auf diesem Weg den verwundbaren Pfad erreichen konnte.

Schließe zuerst Apply auf dem Host ab.
Führe sudo ./inject-netns.sh auf dem Host aus. Es lädt dasselbe Ruleset in jeden laufenden LXC-Container (über pct/lxc-info, Proxmox) und jeden laufenden Docker-Container (Container im Host-Netzwerk werden übersprungen).
Vergleiche die Ausgabe mit der Tabelle.

Ausgabe	Bedeutung
`ok lxc:<id>` oder `ok docker:<id>`	Ruleset in diesem Container-Namespace geladen
`injected=N failed=M`	Summen, M sollte 0 sein

Die Injektion ist nicht persistent. Sie geht verloren, wenn ein Container neu startet, daher führe das Skript nach Neustarts erneut aus. Docker-Container, die in einem LXC-Container verschachtelt sind, erfordern, dass das Skript innerhalb dieses LXC-Containers ausgeführt wird (nicht gemessen).

Gemessenes Ergebnis: Über 5 Proxmox-Hosts wurden 64 Container-Namespaces mit 0 Fehlern injiziert. Nach der Injektion lief derselbe Test in einen Timeout und der Drop-Zähler des Container-Namespace stieg an.

If something breaks

Das Symptom einer Störung durch diese Mitigation ist eine TCP-Verbindung, die hängt (in einen Timeout läuft), anstatt abgelehnt zu werden, zusammen mit einem steigenden Zähler in der Ausgabe von:

nft list ruleset | grep counter

Befehl	Wirkung
`systemctl stop cve-2026-98432-mitigation`	sofort aus, kommt beim Neustart wieder
`systemctl disable --now cve-2026-98432-mitigation`	jetzt aus und über Neustarts hinweg

Kompatibilität gemessen auf den getesteten Hosts: Die Regeln liegen in eigenen Tabellen und koexistierten mit Docker, ufw, iptables-legacy-NAT-Regeln und NetBird-(WireGuard-)Routing. Normale TCP-Verbindungen funktionierten auf jedem getesteten Pfad weiterhin. Die Drop-Zähler blieben während des Normalbetriebs auf den Werten der Testpakete (kein legitimer Traffic traf zu) über ein kurzes Beobachtungsfenster (Stunden, nicht Tage).

Beliebteste