Fissa un tag di release per il controllo delle modifiche: https://raw.githubusercontent.com/haydenjames/dirty-frag-check/v1.0.4/dirty-frag-check.sh.

-q per output su una riga per la flotta. -h per l'aiuto. Uscita 0 ok, 1 vulnerabile, 2 sconosciuto.

Uso su flotta

I codici di uscita (0 ok, 1 vulnerabile, 2 sconosciuto) funzionano con qualsiasi strumento che aggrega per stato.

Requisiti

bash 4+, più i soliti awk/grep/sed/lsmod/modprobe. Non serve root per il controllo in sé. L'applicazione delle mitigazioni richiede invece root.

Cosa controlla

1. Stato dei moduli. Se i moduli implicati dall'advisory — esp4, esp6, ipcomp, ipcomp6 (CVE-2026-43284) e rxrpc (CVE-2026-43500) — sono caricati, disponibili o assenti.
2. Mitigazioni. Cerca i file di blacklist di modprobe e verifica che la blacklist abbia effettivamente effetto tramite modprobe -n -v. Riporta lo stato di SELinux e AppArmor. Rileva il livepatch KernelCare tramite kcarectl --patch-info.
3. Pacchetto kernel vs. kernel in esecuzione. Individua il caso in cui hai installato un kernel patchato ma non hai ancora riavviato su di esso.
4. Kernel in esecuzione vs. versione nota corretta. Per le distribuzioni della famiglia RHEL (AlmaLinux, Rocky, RHEL, CloudLinux), confronta uname -r con la versione corretta pubblicata dal vendor per quella release. Best-effort; verifica sul tracker della tua distribuzione.

Verdetti

• OK — Livepatch KernelCare applicato, kernel in esecuzione uguale o successivo alla correzione pubblicata, o tutti i moduli rilevanti in blacklist.
• MITIGATO — kernel non patchato ma ogni modulo raggiungibile è in blacklist, quindi il bug non può essere sfruttato. Applica la patch appena possibile.
• RIBOOT NECESSARIO — kernel patchato installato, sei ancora su quello vecchio.
• VULNERABILE — kernel in esecuzione verificato più vecchio della correzione ed è disponibile un aggiornamento del kernel, oppure moduli caricati con un aggiornamento in sospeso.
• IN ATTESA DI PATCH DEL VENDOR — kernel in esecuzione più vecchio della correzione upstream, nessun aggiornamento del kernel attualmente disponibile. Comune su Rocky/CloudLinux che seguono AlmaLinux con un build di ritardo, o quando la distribuzione fa backport con una stringa di versione diversa.
• A RISCHIO — host gestito da KernelCare senza ancora il livepatch Dirty Frag, oppure moduli disponibili con un aggiornamento in sospeso.
• PROBABILMENTE PATCHATO — moduli caricati ma il kernel in esecuzione è uguale o successivo alla correzione pubblicata. Lo script non può ispezionare il livello di patch di un modulo caricato; si affida ai metadati del vendor.
• SCONOSCIUTO — nessuna tabella delle versioni corrette per questa distribuzione (Ubuntu, Debian, TuxCare ELS) e nessun altro segnale forte. Incrocia i dati sul tracker della distribuzione.

Mitigazione tampone

Usala quando la tua distribuzione non ha ancora rilasciato un aggiornamento del kernel, oppure quando non puoi riavviare a breve e hai bisogno di scaricare i moduli raggiungibili:

Se rmmod dice "module is in use", qualcosa sulla macchina usa attivamente IPsec o AF_RXRPC (alcune VPN, client AFS, strongSwan, Libreswan). Non forzare lo scaricamento. Applica la patch al kernel e riavvia invece.

Utenti KernelCare / TuxCare ELS: i livepatch per CVE-2026-43284 coprono questo senza riavvio. Controlla kcarectl --patch-info.

Obiettivi

Pensato per AlmaLinux 8/9/10, Rocky, RHEL, CloudLinux 8/9/10, Ubuntu, Debian e CentOS 7 (TuxCare ELS / KernelCare). La tabella delle versioni corrette è specifica per la famiglia RHEL; Ubuntu/Debian ripiegano sulla freschezza del gestore pacchetti. Conferma qualsiasi verdetto verde sul tracker della tua distribuzione.

Discussione

• Advisory AlmaLinux: Dirty Frag
• CloudLinux / KernelCare: mitigazione e aggiornamento del kernel
• cPanel: advisory di sicurezza
• Thread del forum: script di controllo Dirty Frag (linuxcommunity.io)
• Checker complementare: CVE-2026-31431-check
• Problemi: GitHub

Licenza

MIT — vedi LICENSE.