illuscapital/cve-2026-98432nftables-Regelsatz und systemd-Unit, die IPv4-TCP-Pakete mit IP-Optionen verwerfen, um die Use-after-free-Schwachstelle CVE-2026-98432 im Linux-Kernel abzumildern, bis ein gepatchter Kernel verfügbar ist.
Eine Übergangs-Firewall-Mitigation für CVE-2026-98432 auf Ubuntu 24.04 (noble), für Hosts, die einen öffentlichen TCP-Listener bereitstellen (z. B. einen Geth-Node auf Port 30303), solange noch kein gepatchter Kernel verfügbar ist.
CVE-2026-98432 ist eine Use-after-free-Schwachstelle im IPv4-TCP-Handshake-Code des Linux-Kernels. Wenn ein eingehendes SYN IPv4-IP-Optionen enthält, werden diese an den neuen Child-Socket weitergegeben, ohne kopiert zu werden; ein gleichzeitig auf einer anderen CPU verarbeitetes, erneut übertragenes SYN kann sie dann lesen, nachdem sie bereits freigegeben wurden. Ein zweiter Auslöser existiert über die Request-Socket-Migration (net.ipv4.tcp_migrate_req=1 oder ein BPF_SK_REUSEPORT_SELECT_OR_MIGRATE-Programm).
Ubuntu stuft die Schwachstelle als hohe Priorität ein (CVSS 3: 9.8). Zum Zeitpunkt der Erstellung ist der Fix für den noble-linux-Kernel noch in Arbeit.
MPTCP-Listener sind kein separater Fall. Go-1.24+-Binaries (einschließlich aktueller Geth-Versionen) öffnen Listener standardmäßig als MPTCP, sodass ss sie als mptcp anzeigt. MPTCP-Subflows durchlaufen denselben IPv4-TCP-SYN-Pfad und sind daher exakt genauso exponiert wie reines TCP. Das Deaktivieren von MPTCP (GODEBUG=multipathtcp=0) behebt dieses Problem nicht.
Eine einzelne nftables-Regel in einer eigenen Tabelle verwirft jedes IPv4-TCP-Paket, dessen Header-Länge nicht 5 beträgt (d. h. alles, was IP-Optionen enthält), bevor der TCP-Stack des Kernels es sieht:
ip protocol tcp ip hdrlength != 5 counter drop
ip hdrlength != 5) verwarf auch IGMP-Membership-Queries, die die Router-Alert-Option tragen, und kann LAN-Multicast (mDNS/Avahi, Casting) stillschweigend beeinträchtigen.inet cvefix), sodass sie mit ufw koexistiert und von ufw-Reloads nicht berührt wird.| Datei | Installation nach | Zweck |
|---|---|---|
nftables-cve-2026-98432.nft | /etc/nftables-cve-2026-98432.nft | Das Ruleset (idempotent; kann gefahrlos erneut ausgeführt werden) |
cve-2026-98432.service | /etc/systemd/system/cve-2026-98432.service | Oneshot-Unit, die das Ruleset beim Booten lädt |
Fügen Sie diese Regel nicht in
/etc/nftables.confein. Diese Datei beginnt mitflush ruleset, was die Regeln von ufw löschen würde, wennnftables.serviceausgeführt wird.
git clone <this-repo> && cd <this-repo>
sudo install -m 0644 nftables-cve-2026-98432.nft /etc/nftables-cve-2026-98432.nft
sudo install -m 0644 cve-2026-98432.service /etc/systemd/system/cve-2026-98432.service
sudo systemctl daemon-reload
sudo systemctl enable --now cve-2026-98432.service
sudo nft list table inet cvefix
Bestätigen Sie außerdem, dass der Migrationsauslöser deaktiviert ist (Standard):
sysctl net.ipv4.tcp_migrate_req # expect: 0
Installiere nping. Unter Ubuntu ist es im Paket nmap enthalten; es gibt kein separates nping-Paket:
sudo apt install nmap
Laden Sie zuerst das Regelset neu, um den Zähler auf 0 zurückzusetzen, und senden Sie dann ein normales SYN (ohne IP-Optionen) über Loopback:
sudo nft -f /etc/nftables-cve-2026-98432.nft # reload; resets the counter to 0
sudo nping --tcp -p 30303 --flags syn -c 3 127.0.0.1
sudo nft list table inet cvefix
Erwartet: SA-Antworten (SYN-ACK), die zeigen, dass der Listener weiterhin erreichbar ist, und der Zähler bleibt bei packets 0 bytes 0. Wenn Sie keine Antworten erhalten, kann nping möglicherweise nicht auf dem Loopback-Interface erfassen; führen Sie in diesem Fall diesen Test und den nächsten gegen die LAN-IP des Hosts anstelle von 127.0.0.1 aus.
Senden Sie dasselbe SYN, diesmal mit einer IP-Option (Record Route). Loopback-Verkehr durchläuft den Prerouting-Hook, sodass dies die Regel ohne Zwischenschicht testet:
sudo nping --tcp -p 30303 --flags syn --ip-options R -c 3 127.0.0.1
sudo nft list table inet cvefix
Erwartet: nping erhält keine Antworten (Lost: 3 (100.00%)), und der Zähler zeigt genau:
ip protocol tcp ip hdrlength != 5 counter packets 3 bytes 240 drop
(3 Probes × 80 Bytes.)
Remote-Tests prüfen die Regel nur, wenn die Probe den Host tatsächlich erreicht. Auf einem anderen Rechner im selben LAN richten Sie sich an die LAN-Adresse des Hosts:
sudo nping --tcp -p 30303 --flags syn --ip-options R -c 3 <host-lan-ip>
Prüfen Sie dann den Zähler auf dem geschützten Host:
sudo nft list table inet cvefix
Erwartet: keine Antworten, und der Zähler erhöht sich um 3 (auf packets 6 bytes 480, wenn Sie Schritt 2 zuerst ausgeführt haben).
Das Probing der öffentlichen IP von außen ist in der Regel nicht aussagekräftig. Viele Router und ISP-Geräte verwerfen IP-Options-Pakete selbst. Ein typisches Anzeichen ist eine RA-Antwort (Reset) mit einer hohen TTL wie ttl=250, was auf ein Gerät mit einer anfänglichen TTL von 255 statt auf einen Linux-Host (anfängliche TTL 64) hindeutet. Die Probe erreicht den Host nie, sodass sich der Zähler nicht bewegt. Schritt 4 zeigt, wie man das erkennt.
Führen Sie diese auf dem geschützten Host aus.
Bestätigen, dass Remote-Probes ankommen. Starten Sie dies und wiederholen Sie dann die Probe aus Schritt 3 von der anderen Maschine:
sudo tcpdump -ni any 'tcp port 30303 and (ip[0] & 0x0f) > 5'
| tcpdump auf dem Host | nft-Zähler | nping-Antwort | Bedeutung |
|---|---|---|---|
| zeigt Pakete | steigt | keine | Mitigation funktioniert |
| zeigt Pakete | unverändert | SA | Regel nicht aktiv; prüfe nft list table inet cvefix |
| nichts | unverändert | keine oder RA | Probe wurde upstream gestoppt; teste vom LAN oder Loopback aus |
Bestätigen, dass nichts anderes abgefangen wird. Lass den Zähler mehrere Minuten in Ruhe; er sollte bei deinem Testzählerstand bleiben. Um eingehenden Nicht-TCP-Verkehr mit Optionen zu sehen (den diese Regel absichtlich durchlässt):
sudo tcpdump -ni any '(ip[0] & 0x0f) > 5 and not tcp'
IGMP-Abfragen vom LAN-Router (z. B. igmp query v3 an 224.0.0.1) sind normal und sollten den Zähler nicht erhöhen.
systemctl is-enabled cve-2026-98432.service # expect: enabled
sudo nft list table inet cvefix # table present
sysctl net.ipv4.tcp_migrate_req # expect: 0
Dies ist eine Übergangslösung. Prüfen Sie regelmäßig auf den gepatchten Kernel:
uname -r
sudo pro fix CVE-2026-98432
Wenn ein Fix verfügbar ist:
sudo apt update && sudo apt full-upgrade
sudo reboot
Livepatch (über ein kostenloses persönliches Ubuntu-Pro-Abonnement; pro status, canonical-livepatch status) kann den Neustart vermeiden, aber es gibt keine Garantie, dass ein Livepatch für diese CVE bereitgestellt wird.
Sobald ein gepatchter Kernel läuft (ihn zu behalten ist ebenfalls harmlos):
sudo systemctl disable --now cve-2026-98432.service
sudo nft delete table inet cvefix
sudo rm /etc/systemd/system/cve-2026-98432.service /etc/nftables-cve-2026-98432.nft
sudo systemctl daemon-reload
Für zusätzlichen Spielraum bis zum Patchen kann eingehender Datenverkehr auf 30303 vollständig geschlossen werden (Geth synchronisiert weiterhin über ausgehende Peers, mit weniger Peers):
sudo ufw deny 30303/tcp
# later:
sudo ufw delete deny 30303/tcp