Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
cve-2026-98432 — Mitigations-Toolkit für den IPv4-TCP-Use-after-free in inet_opt/ireq_opt: Expositionsprüfung, nft-Drop-Regeln für SYN mit IP-Optionen, tcpdump-Erkennung und kpatch/livepatch-Builder für EL-Kernel. | Kitploit
Tools/GitHubGitHub/davetha/cve-2026-98432
DefensivwerkzeugePaket-Sniffing & AnalyseSchwachstellenanalyseKonfigurationsprüfungNetzwerksicherheitIncident Response
GitHubdavetha/cve-2026-98432

cve-2026-98432

Mitigations-Toolkit für den IPv4-TCP-Use-after-free in inet_opt/ireq_opt: Expositionsprüfung, nft-Drop-Regeln für SYN mit IP-Optionen, tcpdump-Erkennung und kpatch/livepatch-Builder für EL-Kernel.

Repository anzeigen
112vor 6 TagenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-98432 Mitigation-Toolkit

IPv4-TCP-inet_opt/ireq_opt-Use-after-free (Upstream-Fix e3f33b0a, kfree → kfree_rcu in inet_sock_destruct() + tcp_v4_reqsk_destructor()). Auslöser: Client-SYN mit IPv4-Optionen (ihl > 5) — ohne Optionen wird das umkämpfte Objekt ireq_opt nie alloziert. Der behauptete Remote-Root-Exploit benötigt zusätzlich einen MPTCP-Listener.

Dateien

Dateibenötigt RootZweck
cve-audit.shneinschreibgeschützter Expositions- und Patchbarkeitsbericht
cve-mitigate.shanwenden/rückgängig machennft-Drop von SYNs mit IP-Optionen, optional MPTCP aus
nft-rules.txt—das Regelset eigenständig (nft -f nft-rules.txt)
cve-detect.shCapture-Moditcpdump-Sensor für die Paketform des Exploits
kpatch-el-build.shbauen/installierenvalidierter kpatch/Livepatch-Builder für die EL-Familie
klp-handcraft-build.shbauen/ladenhandgeschriebenes klp-Modul für IBT-Kernel, auf denen kpatch-build nicht laufen kann (EL10)
patches/CVE-2026-98432.patch—Upstream-Fix, bereit für kpatch-build
tests/run-tests.shneinHarness (netns-Regelset-Laden + Stub-Builder-E2E)

Incident-Schnellstart

./cve-audit.sh                                # where do I stand?
./cve-mitigate.sh apply --with-mptcp-off      # closes trigger + claimed root path
./cve-detect.sh count 30                      # anyone probing with IP options?
sudo ./kpatch-el-build.sh --name CVE-2026-98432 \
     --expect inet_sock_destruct,tcp_v4_reqsk_destructor \
     [--sign priv.pem cert.pem] [--install] \
     patches/CVE-2026-98432.patch
# verify: cat /sys/kernel/livepatch/CVE-2026-98432/enabled  -> 1
./cve-mitigate.sh status                      # keep until 100% patched, then:
./cve-mitigate.sh undo

EL-Matrix

ZielHinweise
EL7 (3.10)nicht anfällig (Trigger-Code kam in 4.4); Builder funktioniert weiterhin für andere Patches
EL7h/EL8 (4.18)anfällig; kernel-debuginfo liefert /usr/src/debug/kernel-*/linux-*; kpatch-build aus EPEL
EL9 (5.14)anfällig; Kernel mit gcc-toolset gebaut — Builder stellt automatisch das passende /opt/rh/gcc-toolset-* voran
EL10 (6.12)IBT: kpatch-build 0.9.11 lehnt CONFIG_X86_KERNEL_IBT=y-Kernel ab (dynup/kpatch#1320) — klp-handcraft-build.sh verwenden; Modul-Signierung wird unter Secure Boot/Lockdown erzwungen
CloudLinux 8/9/10Distro-ID nicht in der Support-Liste von kpatch-build, daher übergibt der Builder immer explizit -s/-c/-v; Debuginfo stammt aus dem AlmaLinux/CentOS kernel-debuginfo passend zu rpm -qf /boot/vmlinuz-$(uname -r)

Debuginfo unter RHEL erfordert aktivierte Repos, z. B. dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms usw. auf nicht abgerechneten Hosts).

Was der Builder validiert, bevor du irgendetwas lädst

  1. CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y in der laufenden Konfiguration.
  2. Ziel-Kernel == laufender Kernel (Vermagic-Mauer), kernel-devel/debuginfo/vmlinux vorhanden.
  3. Patch wird vorwärts angewendet; wenn er rückwärts angewendet wird, wird dir mitgeteilt, dass der Kernel den Fix bereits enthält (kpatch würde später mit „no functional changes" abbrechen).
  4. Compiler stimmt mit dem Build-gcc des Kernels überein (Prüfung auf .comment-Ebene an kpatch-build delegiert; Toolset-Suche hier durchgeführt).
  5. Nach dem Build: Vermagic und eine strikte zweiseitige Allowlist der geänderten Funktionen (--expect) — ein überraschendes drittes Änderungsobjekt ist ein harter Fehler.
  6. Optional sign-file mit deinem Schlüsselpaar + erneute Prüfung von modinfo sig_type; Zertifikat per MOK für Secure Boot registrieren.
  7. --install legt die Datei in /var/lib/kpatch/$(uname -r)/ ab, lädt sie via kpatch/insmod und aktiviert kpatch.service für Persistenz über Neustarts.

Canary-Runbook (vor dem Flotten-Rollout durchführen)

  1. Canary-VM mit demselben uname -r wie die Flotte.
  2. ./kpatch-el-build.sh ... --install; bestätige /sys/kernel/livepatch/<name>/enabled == 1.
  3. Race-Hammer: von einer zweiten Maschine aus hping3 -S -p <port> --tcp-opts ...-Flood auf einen Listener, während auf dem Canary net.ipv4.tcp_migrate_req=1 umgeschaltet wird; eine KASAN-Kernel-Variante mit künstlichem udelay() innerhalb von ip_options_build() sollte die UAF ohne den Patch reproduzieren und mit ihm still bleiben.
  4. Beobachte, dass uname -r unverändert bleibt (Livepatch erhöht es nicht), kpatch list, dmesg -w auf taint und klp-Übergangsstockungen (/sys/kernel/livepatch/<name>/transition muss auf 0 abfließen).
  5. Flotte ausrollen; die nft-Regel 24–48 h nach 100 % Abdeckung entfernen.
  6. Beim nächsten Wartungsfenster unabhängig davon in den Vendor-Kernel neu starten — Livepatches stapeln sich schlecht über Kernel-Versionssprünge hinweg.

Status / Ehrlichkeit

Harness: alle Prüfungen bestehen auf einer AlmaLinux 10.2 VM (Kernel 6.12.0-211.64.1.el10_2). Echte nft-Rulesets werden geladen und in einem frischen netns aufgelistet; pcap-Filter gegen laufendes tcpdump kompiliert; Builder-Pipeline end-to-end gegen ein gestubbtes kpatch-build mit einem echten .ko-Fixture und injizierten Symbol-Feeds ausgeführt.

Auf dieser EL10-VM live verifiziert:

  • klp-handcraft-build.sh --load hat einen Livepatch gebaut und aktiviert: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, Übergang abgeschlossen, sysfs listet inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1; normales TCP (HTTP 200) unbeeinträchtigt. Ein unsigniertes .ko verunreinigt den Kernel; Secure-Boot- Lockdown würde es ablehnen (die VM lief unsigniert).
  • Echtes kpatch-build (dynup 0.9.11, aus dem Quellcode gebaut) schlägt auf EL10 hart fehl mit „kernel option CONFIG_X86_KERNEL_IBT not supported“ — der Builder führt jetzt eine Vorabprüfung durch und verweist auf den Handcraft-Weg. Ein echter binärvergleichender kpatch-build-Lauf bleibt auf EL8/EL9 unerprobt.
  • Mitigation live: 20 Scapy-Option-SYNs über die Leitung wurden von der Guard-Regel gezählt und verworfen; 3 einfache SYNs passierten; ssh unbeeinträchtigt.
  • Feldfund: Auf EL10 6.12.0-211 treffen präparierte SYNs mit IP-Optionen den nft-prerouting-Raw-Hook (-300), erreichen aber nie den INPUT-Hook (offener Port, lo und sauberes netns reproduzieren dies alle; kein kfree_skb-Tracepoint-Ereignis, obwohl SELinux perf/kprobes blockierte und tcpdump nichts aufzeichnete, sodass die genaue Drop-Funktion ungeklärt bleibt). Die Mitigationskette hakt daher am prerouting priority raw ein, der sie beobachtet und verwirft; eine Regel eines Freundes bei prerouting priority -310 funktioniert aus demselben Grund. Führe den Happy Path einmal auf deinem EL-Canary aus, bevor du ihm in einem Incident vertraust.
Tool herunterladen