Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
cve-2026-98432 — Toolkit di mitigazione per la use-after-free di IPv4 TCP inet_opt/ireq_opt: audit dell'esposizione, regole nft di drop dei SYN con opzioni IP, rilevamento tramite tcpdump e builder kpatch/livepatch per kernel EL. | Kitploit
Strumenti/GitHubGitHub/davetha/cve-2026-98432
Strumenti DifensiviSniffing e Analisi dei PacchettiAnalisi delle VulnerabilitàAudit di ConfigurazioneSicurezza di ReteRisposta agli Incidenti
GitHubdavetha/cve-2026-98432

cve-2026-98432

Toolkit di mitigazione per la use-after-free di IPv4 TCP inet_opt/ireq_opt: audit dell'esposizione, regole nft di drop dei SYN con opzioni IP, rilevamento tramite tcpdump e builder kpatch/livepatch per kernel EL.

Vedi Repository
1125 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Toolkit di mitigazione CVE-2026-98432

Use-after-free IPv4 TCP inet_opt/ireq_opt (fix upstream e3f33b0a, kfree → kfree_rcu in inet_sock_destruct() + tcp_v4_reqsk_destructor()). Trigger: SYN del client che trasporta opzioni IPv4 (ihl > 5) — senza opzioni l'oggetto soggetto alla race ireq_opt non viene mai allocato. L'exploit remote-root dichiarato richiede inoltre un listener MPTCP.

File

filerichiede rootscopo
cve-audit.shnoreport di esposizione e patchabilità in sola lettura
cve-mitigate.shapply/undodrop nft dei SYN con opzioni IP, disattivazione MPTCP opzionale
nft-rules.txt—il ruleset autonomo (nft -f nft-rules.txt)
cve-detect.shmodalità capturesensore tcpdump per la forma dei pacchetti dell'exploit
kpatch-el-build.shbuild/installbuilder kpatch/livepatch validato per la famiglia EL
klp-handcraft-build.shbuild/loadmodulo klp scritto a mano per kernel IBT su cui kpatch-build non può essere eseguito (EL10)
patches/CVE-2026-98432.patch—fix upstream, pronto per kpatch-build
tests/run-tests.shnoharness (caricamento ruleset in netns + e2e del builder con stub)

Avvio rapido per l'incidente

./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

Matrice EL

targetnote
EL7 (3.10)non vulnerabile (il codice del trigger è arrivato nella 4.4); il builder funziona comunque per altre patch
EL7h/EL8 (4.18)vulnerabile; kernel-debuginfo fornisce /usr/src/debug/kernel-*/linux-*; kpatch-build da EPEL
EL9 (5.14)vulnerabile; kernel compilato con gcc-toolset — il builder antepone automaticamente il corrispondente /opt/rh/gcc-toolset-*
EL10 (6.12)IBT: kpatch-build 0.9.11 rifiuta i kernel con CONFIG_X86_KERNEL_IBT=y (dynup/kpatch#1320) — usare klp-handcraft-build.sh; la firma dei moduli è imposta con Secure Boot/lockdown
CloudLinux 8/9/10l'id della distro non è nell'elenco di supporto di kpatch-build, quindi il builder passa sempre esplicitamente -s/-c/-v; i debuginfo provengono dal kernel-debuginfo di AlmaLinux/CentOS corrispondente a rpm -qf /boot/vmlinuz-$(uname -r)

I debuginfo su RHEL richiedono l'abilitazione dei repository, ad es. dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms ecc. sugli host non fatturati).

Cosa valida il builder prima di caricare qualsiasi cosa

  1. CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y nella configurazione in esecuzione.
  2. Kernel di destinazione == kernel in esecuzione (muro del vermagic), kernel-devel/debuginfo/vmlinux presenti.
  3. La patch si applica in avanti; se si applica al contrario ti viene detto che il kernel contiene già la correzione (kpatch morirebbe più tardi con "no functional changes").
  4. Il compilatore corrisponde al gcc di build del kernel (controllo a livello di .comment delegato a kpatch-build; la ricerca del toolset avviene qui).
  5. Post-build: vermagic, e una rigorosa allowlist bidirezionale delle funzioni modificate (--expect) — un terzo oggetto modificato inatteso è un fallimento netto.
  6. sign-file opzionale con la tua coppia di chiavi + ricontrollo di modinfo sig_type; registra il certificato tramite MOK per Secure Boot.
  7. --install inserisce in /var/lib/kpatch/$(uname -r)/, carica tramite kpatch/insmod, abilita kpatch.service per la persistenza al riavvio.

Runbook canary (da eseguire prima del rollout sulla flotta)

  1. VM canary, stesso uname -r della flotta.
  2. ./kpatch-el-build.sh ... --install; conferma /sys/kernel/livepatch/<name>/enabled == 1.
  3. Stress test della race: da una seconda macchina, flood con hping3 -S -p <port> --tcp-opts ... verso un listener mentre si alterna net.ipv4.tcp_migrate_req=1 sul canary; una variante del kernel con KASAN e un udelay() artificiale dentro ip_options_build() dovrebbe riprodurre la UAF senza la patch e restare silenziosa con essa.
  4. Verifica che uname -r resti invariato (livepatch non lo incrementa), kpatch list, dmesg -w per taint e stalli di transizione klp (/sys/kernel/livepatch/<name>/transition deve scendere a 0).
  5. Rollout sulla flotta; rimuovi la regola nft 24–48h dopo la copertura al 100%.
  6. Riavvia comunque sul kernel del vendor alla finestra successiva — i livepatch si sovrappongono male tra un aggiornamento del kernel e l'altro.

Stato / trasparenza

Harness: tutti i controlli passano su una VM AlmaLinux 10.2 (kernel 6.12.0-211.64.1.el10_2). Ruleset nft reali vengono caricati ed elencati dentro un netns nuovo; filtri pcap compilati contro tcpdump live; pipeline del builder esercitata end-to-end contro un kpatch-build stubbato con un fixture .ko reale e feed di simboli iniettati.

Verificato dal vivo su quella VM EL10:

  • klp-handcraft-build.sh --load ha compilato e abilitato una livepatch: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, transizione completata, sysfs elenca inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1; il normale TCP (HTTP 200) non è influenzato. Il .ko non firmato contamina il kernel; il lockdown di Secure Boot lo rifiuterebbe (la VM girava senza firma).
  • Il vero kpatch-build (dynup 0.9.11, compilato dai sorgenti) fallisce in modo netto su EL10 con "kernel option CONFIG_X86_KERNEL_IBT not supported" — il builder ora esegue un preflight su questo e rimanda alla via handcraft. Un'esecuzione reale di kpatch-build con diff binario resta non testata su EL8/EL9.
  • Mitigazione attiva: 20 option-SYN scapy sul filo sono stati contati e scartati dalla regola di guardia; 3 SYN semplici sono passati; ssh non è influenzato.
  • Riscontro sul campo: su EL10 6.12.0-211, i SYN costruiti con opzioni IP raggiungono l'hook raw prerouting di nft (-300) ma non arrivano mai all'hook INPUT (porta aperta, lo e netns pulito riproducono tutti il caso; nessun evento tracepoint kfree_skb, sebbene SELinux abbia bloccato perf/kprobes e tcpdump non abbia catturato nulla, quindi la funzione esatta di drop è irrisolta). La catena di mitigazione aggancia quindi prerouting priority raw, che li osserva e li scarta; una regola di un amico a prerouting priority -310 funziona per lo stesso motivo. Esegui una volta il percorso felice sul tuo canary EL prima di fidartene in un incidente.
Scarica lo strumento