Épinglez à un tag de version pour le contrôle des modifications : https://raw.githubusercontent.com/haydenjames/CVE-2026-31431-check/v1.0.3/cve-2026-31431.sh.

-q pour une sortie une ligne par machine. -h pour l'aide. Code de sortie 0 ok, 1 vulnérable, 2 inconnu.

Utilisation en flotte

-q affiche une ligne par hôte, vous pouvez donc le rediriger via n'importe quel gestionnaire distant que vous utilisez déjà :

Les codes de sortie (0 ok, 1 vulnérable, 2 inconnu) fonctionnent également si votre outillage agrège par statut.

Prérequis

bash 4+, plus les habituels awk/grep/sed/lsmod/modprobe. Si python3 est disponible, il testera également l'accessibilité du socket AF_ALG ; sinon, ce contrôle est ignoré. Le contrôle lui-même ne nécessite pas les droits root. L'application de la mitigation en nécessite.

Ce qu'il vérifie

1. État de algif_aead. Intégré, module chargeable, chargé ou absent. Lit /boot/config-* ou /proc/config.gz, sinon utilise lsmod. 1b. État de authencesn. Selon l'avis en amont, c'est le module qui contient réellement le bogue — algif_aead est l'une des voies d'accès, IPsec en est une autre. Détecté via lsmod/modinfo et la configuration.
2. Socket AF_ALG. Si l'espace utilisateur peut réellement en ouvrir un. Détecte les blocages seccomp et LSM (utilise Python si disponible).
3. Mitigations. Recherche les fichiers de blacklist modprobe (pour l'un ou l'autre module) et vérifie que la blacklist est effectivement prise en compte via modprobe -n -v. Signale également la directive DefaultRestrictAddressFamilies systemd [Manager] cassée qui circule — cette directive ne fonctionne que sur les units, pas dans system.conf.d. Rapporte le statut de SELinux et AppArmor.
4. Paquet du noyau vs noyau en cours d'exécution. Détecte le cas où vous avez installé un noyau patché mais n'avez pas redémarré dessus.

Verdicts

• OK — AF_ALG n'est pas accessible, ou le module n'est pas présent, ou votre blacklist fonctionne.
• REDÉMARRAGE NÉCESSAIRE — noyau patché installé, vous êtes toujours sur l'ancien.
• VULNÉRABLE — le module est chargé sans noyau patché installé, ou il est intégré au noyau et un paquet patché est disponible.
• PROBABLEMENT PATCHÉ — le module est chargé mais le noyau en cours d'exécution est à jour. Le script ne peut pas inspecter un module chargé pour différencier une version patchée d'une version vulnérable, donc ce verdict se réfère à votre gestionnaire de paquets. Confirmez auprès du suivi CVE de votre distribution.
• À RISQUE — le module est chargeable et rien ne l'empêche.
• EN ATTENTE DU PATCH DU FOURNISSEUR — le noyau est à jour mais algif_aead est intégré. Verdict de meilleur effort ; il se base sur les codes de sortie de dnf check-update, qui peuvent être non nuls pour des raisons non liées (réseau, métadonnées obsolètes). Ne supposez pas que vous êtes bloqué sans vérifier votre suivi de distribution.

Mitigation provisoire

Selon l'avis en amont, le bogue se trouve en fait dans le module crypto authencesn — algif_aead n'est qu'une des voies d'accès. Blacklistez les deux pour être sûr :

Si rmmod dit « le module est utilisé », quelque chose sur la machine utilise activement AF_ALG ou IPsec (certains VPN, chiffrement de disque, outils crypto en espace utilisateur). Ne forcez pas le déchargement. Passez le patch et redémarrez.

Si le code vulnérable est compilé dans votre noyau, le blacklistage ne servira à rien. Seule une mise à jour du noyau le corrige.

Testé sur

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

Discussion

• Avis en amont : liste de diffusion oss-security — source primaire.
• Fil de discussion : CVE-2026-31431 — danger (linuxcommunity.io)
• Problèmes : GitHub

Crédits

Rapports de bogues qui ont façonné la v1.0.1 :

• u/throwaway234f32423df — a signalé que la mise à jour du blacklist kmod d'Ubuntu n'était pas détectée, provoquant de faux verdicts VULNÉRABLE sur des hôtes Ubuntu patchés.
• u/aliendude5300 — a souligné qu'un module chargé et patché sur place signalerait toujours VULNÉRABLE.

Licence

MIT — voir LICENSE.