mahdi-salmanzade/cve-2026-98432Leitfaden und Read-only-Prüfskript für CVE-2026-98432, eine Use-after-free-Schwachstelle in Linux IPv4 TCP: Erkennung des Kernel-Patch-Status, Anwendung einer iptables-Übergangslösung und Überprüfung nach dem Fix.
Über das Netzwerk angreifbar, ohne Anmeldung und ohne Benutzeraktion. Der Fehler steckt im Kernel-Code, der jede eingehende IPv4-TCP-Verbindung verarbeitet.
Diese Anleitung zeigt, wie man einen Server prüft, ihn schützt, bis ein gepatchter Kernel verfügbar ist, und anschließend aufräumt. Die folgenden Befehle wurden auf Servern mit Ubuntu 22.04 und 24.04 verwendet.
Der Status in diesem Dokument entspricht dem Stand vom 30.10.2026. Der Patch-Status ändert sich schnell, prüfe daher immer den eigenen Security-Tracker deiner Distribution.
e3f33b0a1d89In einfachen Worten: Eine Verbindungsanfrage (SYN) kann IPv4-Optionen enthalten, selten genutzte Zusatzangaben im Paketkopf wie Record Route oder Timestamp. Wenn eine solche eintrifft, legt der Kernel eine Kopie dieser Optionen an. Sendet der Angreifer das SYN im genau richtigen Moment erneut, kann eine CPU diese Kopie freigeben, während eine andere sie noch zum Aufbau der Antwort verwendet. Das ist ein Use-after-free in ip_options_build(), und es kann den Server zum Absturz bringen oder den Kernel-Speicher beschädigen.
Ein zweiter Auslöser existiert, wenn der Server ausstehende Verbindungsanfragen zwischen Sockets migriert (net.ipv4.tcp_migrate_req=1 oder ein BPF_SK_REUSEPORT_SELECT_OR_MIGRATE-Programm). Diese Einstellung ist standardmäßig deaktiviert.
| Ubuntu-Priorität | Hoch |
| CVSS, Kernel-CNA | 9,8 Kritisch: Netzwerk, keine Authentifizierung, keine Benutzerinteraktion |
| CVSS, Red Hat | 8,1, da Red Hat die Race-Condition als schwerer auslösbar einschätzt |
| Betroffen | Kernel seit 4.4 |
| IPv6 | Vom Hauptproblem nicht betroffen |
| Ausnutzung | Keine Berichte aus der Praxis und nicht im CISA-KEV-Katalog. Ein Remote-Root-Exploit gegen Server mit einem Multipath-TCP-(MPTCP-)Listener wurde gemeldet, aber nicht veröffentlicht. |
Wer ist exponiert: jeder Server mit einem über IPv4 erreichbaren TCP-Port, sei es SSH, HTTP, HTTPS oder etwas anderes.
| Distribution | Status | Behoben in |
|---|---|---|
| Upstream-Kernel | ✅ Behoben | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 |
| Debian 12 / 13 | ✅ Behoben | 6.1.190-1 (oder linux-6.12 6.12.113-1~deb12u1) / 6.12.113-1 |
| Ubuntu 26.10 / 26.04 / 24.04 / 22.04 | ❌ Fix in Arbeit, nicht veröffentlicht | Geplant: 7.3.0-10.10 / 7.0.0-43.43 / 6.8.0-149.149 / 5.15.0-203.213 |
| Ubuntu 20.04 / 18.04 / 16.04 | ❌ Anfällig | Nur über Ubuntu Pro (ESM), wenn überhaupt |
| RHEL 8 / 9 / 10 | ❌ Gemeldet als "Fix zurückgestellt" | Keine |
| Oracle Linux (UEK) | ✅ Behoben | ELSA-2026-500397 / 500398 / 500399 |
| Amazon Linux 2023 | ⚠️ Teilweise behoben | kernel6.18 und kernel6.12 behoben; Standard-Kernel und AL2 ausstehend |
| SUSE | ⚠️ Teilweise behoben | openSUSE Leap 16.0 behoben; SLES in Arbeit |
Ubuntu-Cloud-Kernel (-aws, -azure, -gcp, -oracle) haben eigene Versionsnummern. Distributions-Kernel backporten Fixes, daher sollte man eine Distributionsversion wie 5.15.0-xxx nicht mit den Upstream-Nummern vergleichen.
Dies liest und meldet nur. Es installiert, ändert oder startet nichts neu. Füge es in ein Terminal auf dem Server ein:
sudo bash -s <<'EOF'
CVE=CVE-2026-98432; FIX="free inet_opt and ireq_opt"; KR=$(uname -r)
. /etc/os-release
echo "== $PRETTY_NAME | running kernel: $KR"; echo " build: $(uname -v)"
echo "== Installed kernels (if one is newer than the running kernel, you need a reboot)"
ls -1v /boot/vmlinuz-* 2>/dev/null | sed 's|/boot/vmlinuz-| |'
[ -f /var/run/reboot-required ] && echo " !! reboot required"
echo "== Is the fix in the RUNNING kernel's changelog?"
if command -v dpkg >/dev/null; then
dpkg-query -W -f=' package version: ${Version}\n' "linux-image-$KR" 2>/dev/null
zgrep -Eqs "$CVE|$FIX" /usr/share/doc/linux-*"$KR"*/changelog.Debian.gz \
&& echo " PATCHED" || echo " NOT FOUND -> likely VULNERABLE"
command -v pro >/dev/null && pro fix "$CVE" --dry-run </dev/null
elif command -v rpm >/dev/null; then
PKG=$(rpm -qf "/lib/modules/$KR/vmlinuz" "/usr/lib/modules/$KR/vmlinuz" "/boot/vmlinuz-$KR" 2>/dev/null | grep -v 'not owned' | head -1)
echo " package: ${PKG:-unknown}"
rpm -q --changelog "$PKG" 2>/dev/null | grep -Eq "$CVE|$FIX" \
&& echo " PATCHED" || echo " NOT FOUND -> likely VULNERABLE"
if command -v zypper >/dev/null; then zypper -n -q lp -a --cve="$CVE" </dev/null
elif command -v dnf >/dev/null; then dnf -q updateinfo list --all --cve="$CVE" </dev/null
elif command -v yum >/dev/null; then yum -q updateinfo list --cve="$CVE" </dev/null; fi
fi
echo "== Exposure"
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req 2>/dev/null | sed 's/^/ /'
M=$(ss -lnMH 2>/dev/null); echo " MPTCP listeners (reported root-exploit path): ${M:-none}"
echo " TCP listeners not on loopback (attack surface):"
ss -ltnH | awk '$4 !~ /^(127\.|\[::1\])/ {print " "$4}' | sort -u
EOF
Fügen Sie es vollständig ein: Das abschließende EOF muss in einer eigenen Zeile ohne führende Leerzeichen stehen.
Die Ausgabe lesen:
| Was Sie sehen | Bedeutung | Nächster Schritt |
|---|---|---|
PATCHED | Der laufende Kernel enthält den Fix bereits | Sie sind fertig |
NOT FOUND -> likely VULNERABLE | Kein Fix im laufenden Kernel | Schritt 2 |
!! reboot required oder ein neuerer Kernel als der laufende wird aufgeführt | Ein neuerer Kernel ist installiert, läuft aber noch nicht | Schritt 3 |
A fix is coming soon (Ubuntu) | Ubuntu hat den Fix noch nicht ausgeliefert | Jetzt Schritt 2, später Schritt 5 |
MPTCP listeners: none | Der gemeldete Root-Exploit-Pfad trifft derzeit nicht zu | — |
Ein Datenbank- oder Cache-Port wie *:3306, 0.0.0.0:6379 oder 0.0.0.0:11211 | Er lauscht auf allen Schnittstellen | Stellen Sie sicher, dass die Firewall ihn blockiert (siehe Ende von Schritt 4) |
Die folgende Regel verwirft IPv4-TCP-Pakete, die IP-Optionen enthalten, was ein Angreifer benötigt, um den Fehler auszulösen. Normale Clients (Browser, SSH, Telefone, APIs, Load Balancer) senden niemals IP-Optionen, sodass echter Datenverkehr nicht beeinträchtigt wird.
Prüfen Sie zunächst, welches Firewall-Tool der Server verwendet:
systemctl is-active ufw nftables firewalld
Wenn nftables oder firewalld active ist, kann das Neuladen dieser Firewall diese Regel entfernen. Verwende die nftables-Variante am Ende dieses Schritts oder passe sie an deine Umgebung an.
Installiere die Übergangslösung. Es ist eine kleine systemd-Unit, sodass die Regel nach jedem Neustart wiederhergestellt wird:
sudo tee /etc/systemd/system/cve-2026-98432.service >/dev/null <<'EOF'
[Unit]
Description=Stopgap for CVE-2026-98432: drop IPv4 TCP packets carrying IP options
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m comment --comment CVE-2026-98432 -j DROP
ExecStop=/usr/sbin/iptables -t raw -D PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m comment --comment CVE-2026-98432 -j DROP
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now cve-2026-98432
sudo iptables -t raw -L PREROUTING -v -n
Der letzte Befehl sollte eine DROP-Regel mit dem Kommentar CVE-2026-98432 auflisten. Die Spalte pkts zählt die Pakete, die sie blockiert hat; sie sollte bei 0 oder nahe daran bleiben.