johnhsb/linux-tcp-uaf-cve-2026-98432CVE-2026-98432 (Linux IPv4 TCP inet_opt UAF): schreibgeschütztes Diagnoseskript, nftables/sysctl-Mitigationen ohne Neustart, Ansible-Rollout und Reaktionsleitfaden (EN/KO)
Ein Response-Kit für CVE-2026-98432, einen Speichersicherheitsfehler im Code, den der Linux-Kernel zum Aufbau von TCP-Verbindungen verwendet. Es enthält drei Dinge:
iptables oder nftables, wo iptables fehlt), Kernel-Einstellungsdateien (sysctl) und Ansible-Playbooks, die alle ohne Neustart angewendet werden. Der Standardmodus zählt nur Pakete.Verfasst mit Stand 2026-11-03. Jede Mitigation hier ist temporär und ersetzt nicht den Kernel-Fix. Planen Sie das Kernel-Update und den Neustart (oder einen Livepatch) separat ein.
| README | Leitfaden | Diagnoseskript | |
|---|---|---|---|
| 🇺🇸 Englisch (Standard) | README.md | cve-2026-98432-guide.en.md | check_cve_2026_98432.sh |
| 🇰🇷 한국어 | README.ko.md | cve-2026-98432-guide.ko.md | check_cve_2026_98432_ko.sh |
iptables und erfordert keinen Neustart. Um sicher zu sein, beginnt sie mit reinem Zählen; wechseln Sie zum Verwerfen, sobald Sie bestätigt haben, dass kein legitimer Datenverkehr betroffen ist.Der IP-Header einer TCP-Verbindungsanfrage kann — selten — zusätzliche Felder namens IPv4-Optionen enthalten. Der Kernel hält diese Optionen im Speicher, während die Verbindung aufgebaut wird. Bei der Bereinigung gab er diesen Speicher sofort frei, obwohl ein anderer CPU-Kern ihn noch lesen konnte.
Die Verwendung von Speicher nach seiner Freigabe wird als Use-after-free (UAF) bezeichnet. Wenn in der Zwischenzeit etwas anderes dort abgelegt wurde, liest der Kernel die falschen Daten, was zu Folgendem führen kann:
| Punkt | Detail |
|---|---|
| Betroffen | Linux 4.4 und neuer, vor der gepatchten Version des jeweiligen Zweigs. IPv6 ist nicht betroffen |
| Schweregrad | CVSS 9.8 (Kritisch) laut Kernel-CNA, Red Hat und Ubuntu. SUSE, Amazon und Oracle bewerten ihn mit 8.1, da das Gewinnen des Timing-Wettlaufs zwischen CPUs schwierig ist |
| Ursache | Speicher wurde freigegeben, ohne die sichere Freigabeperiode des Kernels (RCU-Grace-Period) abzuwarten. Upstream-Fix: Commit e3f33b0a1d89 (kfree → kfree_rcu) |
| Gepatchte Kernel-Versionen | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 oder neuer — prüfen Sie bei Distributions-Kerneln ob der Fix enthalten ist, nicht die Versionsnummer |
Ausnutzung: Stand 2026-11-03 ist die Schwachstelle nicht in der CISA KEV (dem Katalog der bekanntermaßen ausgenutzten Schwachstellen) aufgeführt, und es wurden keine Angriffe aus der Praxis gemeldet. Viele GitHub-Repositories behaupten, „PoCs“ zu sein; keines ist verifiziert — führen Sie sie nicht in Produktionsnetzwerken aus.
Gepatchte Kernel nach Distribution (Versionen und Quellen in Leitfaden §2.2)
| Distribution | Status |
|---|---|
| RHEL 8 / 9 / 10 | ✅ Gepatchte Kernel am 2026-11-01 veröffentlicht (RHSA-2026:93414 / 93412 / 93413). OpenShift-Knoten (RHCOS) sind noch nicht gepatcht |
| Debian 12 / 13 | ✅ Gepatcht (DSA-6568-1, DLA-4841-1, DLA-4850-1) |
| Amazon Linux 2 / 2023 | ✅ Gepatcht. EKS/ECS-optimierte AMIs, Fargate und Bottlerocket werden schrittweise ausgerollt |
| Rocky Linux (CIQ RLC Pro / LTS) | ✅ Jede von CIQ unterstützte Variante gepatcht. Für Community-Rocky die Rocky Errata prüfen |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | ⏳ In Bearbeitung („work in progress“ Stand 2026-11-03) |
| Ubuntu 16.04 / 18.04 / 20.04 | ⏳ Der Standard-Support ist beendet — Korrekturen werden nur für Ubuntu Pro (ESM)-Abonnenten erwartet |
| SUSE, Oracle Linux, AlmaLinux, … | Korrekturen gemeldet — die jeweilige Herstellerempfehlung prüfen |
Das Diagnoseskript in 4. Was jetzt zu tun ist liefert Ihnen das genaue Ergebnis. Als grobe Orientierung:
Damit ein Angriff funktioniert, benötigt ① der Server mindestens zwei CPU-Kerne (zwei Kerne müssen im selben Moment auf denselben Speicher zugreifen), und ② muss das Paket des Angreifers den Server mit intakten IPv4-Optionen erreichen.
| # | Wenn der Server… | Risiko | Was zu tun ist |
|---|---|---|---|
| 1 | sich in einem internen VPC oder auf einem Kubernetes-Knoten befindet, mehrere Kerne hat und einen MPTCP-Listener (auch in Containern) betreibt | 🔴 Remote-Root | Die Firewall-Regel und sysctl sofort anwenden und die Knoten-Kernel patchen. Einige Kubernetes-Netzwerke (eBPF-basierte CNIs) umgehen die Host-Firewall, daher kommt das Patchen zuerst |
| 2 | eine öffentliche IP hat oder hinter einem L4-Load-Balancer (AWS NLB, …) mit einem MPTCP-Listener steht | 🔴 Remote-Root | Die Firewall-Regel und sysctl sofort anwenden |
| 3 | mehrere Kerne hat und nur gewöhnliche TCP-Dienste betreibt | 🟠 Remote-Absturz | Die Firewall-Regel anwenden (sysctl allein hilft nicht) |
| 4 | eine einzelne CPU (ein vCPU) hat | 🟡 Sehr unwahrscheinlich, dass ein Angriff gelingt | In den regulären Patch-Zyklus aufnehmen |
| 5 | nur über einen L7-Proxy (AWS ALB, CloudFront, Cloudflare, …) mit kontrolliertem internem Zugriff erreichbar ist | 🟡 Angriffspakete kommen nie an | Patchen, um sich gegen interne Angreifer zu verteidigen |