Script di validazione difensiva CVE-2026-23111

Panoramica

CVE-2026-23111 è una vulnerabilità del kernel Linux in nf_tables che può essere sfruttata per l'escalation locale dei privilegi da parte di un utente non privilegiato su sistemi in cui gli user namespace e nftables sono disponibili.[1][2] I bollettini pubblici dei vendor e governativi la descrivono come un problema locale che interessa le distribuzioni Linux e sottolineano l'applicazione delle patch come soluzione primaria.[3][4]

Questo repository contiene uno script di validazione difensiva progettato per aiutare a valutare se un host espone le condizioni tecniche associate a questa CVE senza fornire un exploit per l'escalation dei privilegi. Verifica le condizioni rilevanti del kernel e del runtime, carica opzionalmente il modulo nf_tables per test funzionali completi, tenta un percorso di validazione controllato non privilegiato usando unshare e nft, raccoglie tracce diagnostiche locali e classifica l'host in verdetti operativi come "probabilmente sicuro", "bloccato da policy locale" o "percorso esposto disponibile".[1][5]

Cos'è la CVE

Secondo l'NVD, CVE-2026-23111 è una vulnerabilità nf_tables del kernel Linux risolta come correzione di un bug logico in netfilter ed è sfruttabile per l'escalation locale dei privilegi da parte di un utente non privilegiato tramite user namespace e nftables sulle configurazioni interessate.[1] L'avviso di sicurezza di Ubuntu descrive lo stesso percorso di sfruttamento ad alto livello e traccia gli stati dei pacchetti interessati e corretti per release.[2]

Red Hat dichiara che un utente locale con privilegi bassi potrebbe sfruttare il problema per causare denial of service o potenzialmente ottenere l'escalation dei privilegi, e documenta un percorso di mitigazione basato sull'impedire il caricamento del modulo nf_tables quando ciò è operativamente accettabile.[3] Anche le linee guida a livello nazionale del Canadian Centre for Cyber Security indirizzano le organizzazioni colpite agli aggiornamenti dei vendor e menzionano la rigenerazione dell'initramfs quando vengono utilizzate mitigazioni di blocco dei moduli.[4]

Cosa fa lo script

Lo script è pensato per la valutazione difensiva dell'esposizione, non per lo sfruttamento. È progettato per:

• Identificare il kernel in esecuzione, la famiglia di distribuzione e le relative impostazioni di hardening del runtime.
• Verificare se CONFIG_USER_NS e CONFIG_NF_TABLES risultano presenti.[1]
• Ispezionare kernel.unprivileged_userns_clone e user.max_user_namespaces per stimare se gli user namespace non privilegiati sono disponibili.
• Rilevare se è in atto un deny modprobe rigido (install nf_tables /bin/false) o una blacklist debole per il modulo nf_tables.
• Controllare il changelog RPM del kernel del vendor per una voce di backport di CVE-2026-23111 (solo famiglia RHEL).
• Rilevare l'impronta di /proc/kallsyms per il simbolo vulnerabile (nft_map_catchall_activate) rispetto al simbolo post-patch (nft_catchall_set_activate) prima di qualsiasi interazione con il modulo.
• Caricare opzionalmente nf_tables tramite modprobe quando viene specificato --allow-load-module (vedi sotto) e scaricarlo automaticamente all'uscita.
• Eseguire un passaggio di validazione vincolato unshare -U -n --map-root-user + nft quando il modulo è caricato, e registrare stdout, stderr e i log recenti del kernel.
• Verificare che unshare --user crei effettivamente un namespace e che CAP_NET_ADMIN sia funzionante al suo interno, per confermare se le restrizioni AppArmor o SELinux sono realmente efficaci.
• Evidenziare se i controlli di sicurezza locali come AppArmor o SELinux sembrano bloccare il percorso testato.[6]
• Produrre un output orientato ai verdetti con evidenziazione opzionale a colori per un triage più semplice.

Lo script salva i log in una sottodirectory della directory dello script e li rimuove per impostazione predefinita a meno che non venga usato --keep-logs.

Policy di caricamento del modulo

Per impostazione predefinita lo script non carica mai nf_tables. Se il modulo non è già caricato all'avvio dello script, tutti i test funzionali nft vengono saltati e il verdetto deriva esclusivamente dalla versione del kernel, dall'impronta kallsyms, dalla configurazione di modprobe, dal changelog RPM e dalle evidenze di policy sysctl/LSM.

Questa impostazione predefinita conservativa evita di espandere involontariamente la superficie d'attacco sugli host di produzione. Per abilitare test funzionali completi su un sistema controllato o strumentato, usa --allow-load-module come root (vedi sotto).

Utilizzo

# Default — no module loading, policy-evidence-only verdict
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Full functional test — loads (and unloads) nf_tables, requires root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Opzioni

Opzione	Descrizione
--allow-load-module	Autorizza lo script a caricare nf_tables tramite modprobe se il modulo non è già caricato. Abilita l'esercitatore completo del percorso catchall nft e il test di efficacia di CAP_NET_ADMIN. Il modulo viene scaricato automaticamente all'uscita. Richiede root. Rifiutato se è già in atto un deny modprobe rigido. Utilizzare solo su sistemi non di produzione o strumentati.
--color	Abilita l'output stdout colorato quando il terminale lo supporta.
--keep-logs	Mantiene i log e le tracce nella directory dello script invece di eliminarli all'uscita.
--help	Stampa le informazioni di utilizzo ed esce.

Quando usare --allow-load-module

Usa --allow-load-module quando hai bisogno del verdetto con la massima affidabilità su una VM di test isolata, non di produzione o dedicata. Scenari tipici:

• Un kernel nell'intervallo vulnerabile viene validato prima di implementare la correzione del vendor.
• Il sistema di test ha KASAN o altra strumentazione abilitata e vuoi osservare le tracce del kernel.
• Il modulo non è in uso sull'host target e per le evidenze di audit è richiesto un controllo completo end-to-end del percorso.

Non usare --allow-load-module su host di produzione in cui nf_tables è bloccato intenzionalmente o dove il suo caricamento violerebbe una policy di hardening.

Controlli di sicurezza per --allow-load-module

Prima di tentare di caricare il modulo, lo script applica i seguenti controlli ed esce con un errore se uno di essi fallisce:

1. Un deny modprobe rigido (install nf_tables /bin/false) non deve essere presente in /etc/modprobe.d/.
2. modprobe deve essere disponibile sul sistema.
3. Lo script deve essere eseguito come root (uid 0).

Se il modulo viene caricato con successo dallo script, modprobe -r nf_tables viene chiamato all'uscita tramite il trap cleanup(), indipendentemente da come termina lo script (successo, errore o CTRL+C).

Modello di verdetto

Lo script usa verdetti operativi piuttosto che esiti di sfruttamento: