Fissa un tag di release per il controllo delle modifiche: https://raw.githubusercontent.com/haydenjames/CVE-2026-31431-check/v1.0.3/cve-2026-31431.sh.

-q per un output su una riga per host. -h per l'aiuto. Codice di uscita 0 ok, 1 vulnerabile, 2 sconosciuto.

Uso in flotta

-q stampa una riga per host, quindi puoi passarlo tramite pipe a qualsiasi esecutore remoto che già usi:

Anche i codici di uscita (0 ok, 1 vulnerabile, 2 sconosciuto) funzionano se i tuoi strumenti aggregano per stato.

Requisiti

bash 4+, oltre ai soliti awk/grep/sed/lsmod/modprobe. Se python3 è disponibile, testerà anche la raggiungibilità dei socket AF_ALG; altrimenti quel controllo viene saltato. Il controllo in sé non richiede root. L'applicazione della mitigazione sì.

Cosa controlla

1. Stato di algif_aead. Integrato, modulo caricabile, caricato o assente. Legge /boot/config-* o /proc/config.gz, con fallback su lsmod. 1b. Stato di authencesn. Secondo l'avviso upstream, questo è il modulo che contiene effettivamente il bug — algif_aead è un percorso di raggiungimento, IPsec un altro. Rilevato tramite lsmod/modinfo e la configurazione.
2. Socket AF_ALG. Se lo spazio utente può effettivamente aprirne uno. Rileva blocchi seccomp e LSM (usa Python se disponibile).
3. Mitigazioni. Cerca file di blacklist di modprobe (per entrambi i moduli) e verifica che la blacklist abbia effettivamente la precedenza tramite modprobe -n -v. Segnala anche il trucco DefaultRestrictAddressFamilies di systemd [Manager] rotto che sta circolando — quella direttiva funziona solo sulle unità, non in system.conf.d. Riporta lo stato di SELinux e AppArmor.
4. Pacchetto kernel vs kernel in esecuzione. Rileva il caso in cui hai installato un kernel aggiornato ma non hai ancora riavviato su di esso.

Verdetti

• OK — AF_ALG non è raggiungibile, o il modulo non è presente, o la tua blacklist funziona.
• REBOOT NEEDED — kernel aggiornato installato, sei ancora su quello vecchio.
• VULNERABLE — il modulo è caricato senza un kernel aggiornato installato, oppure è integrato nel kernel ed è disponibile un pacchetto aggiornato.
• LIKELY PATCHED — il modulo è caricato ma il kernel in esecuzione è aggiornato. Lo script non può ispezionare un modulo caricato per distinguere una versione patchata da una vulnerabile, quindi questo verdetto rimanda al tuo gestore di pacchetti. Conferma tramite il tracker CVE della tua distribuzione.
• AT RISK — il modulo è caricabile e nulla lo impedisce.
• WAITING ON VENDOR PATCH — il kernel è aggiornato ma algif_aead è integrato. Verdetto best-effort; si basa sui codici di uscita di dnf check-update, che possono essere diversi da zero per motivi non correlati (rete, metadati obsoleti). Non dare per scontato di dover attendere senza controllare il tracker della tua distribuzione.

Mitigazione temporanea

Secondo l'avviso upstream, il bug vive in realtà nel modulo crittografico authencesn — algif_aead è solo uno dei percorsi di raggiungimento. Metti in blacklist entrambi per sicurezza:

Se rmmod dice "module is in use", qualcosa sulla macchina usa attivamente AF_ALG o IPsec (alcune VPN, crittografia del disco, strumenti di crittografia nello spazio utente). Non forzare lo scaricamento. Applica la patch e riavvia.

Se il codice vulnerabile è compilato nel tuo kernel, la blacklist non aiuta. Solo un aggiornamento del kernel lo risolve.

Testato su

AlmaLinux 8, AlmaLinux 9.7, CentOS 7 (TuxCare ELS), Ubuntu 22.04, Ubuntu 24.04.

Discussione

• Avviso upstream: mailing list oss-security — fonte primaria.
• Discussione sul forum: CVE-2026-31431 — pericolo (linuxcommunity.io)
• Segnalazioni: GitHub

Crediti

Segnalazioni di bug alla base della v1.0.1:

• u/throwaway234f32423df — ha segnalato che l'aggiornamento della blacklist kmod di Ubuntu non veniva rilevato, causando falsi verdetti VULNERABLE su host Ubuntu aggiornati.
• u/aliendude5300 — ha fatto notare che un modulo caricato e poi patchato in loco avrebbe comunque riportato VULNERABLE.

Licenza

MIT — vedi LICENSE.