vcheck

Auditer un hôte Linux distant via SSH pour les vulnérabilités des modules noyau Copy Fail et Dirty Frag et, optionnellement, appliquer des atténuations :

CVE	Nom	Modules affectés
CVE-2026-31431	Copy Fail	algif_aead
CVE-2026-43284	Dirty Frag (IPsec)	esp4, esp6, ipcomp4, ipcomp6, xfrm_user
CVE-2026-43500	Dirty Frag (RxRPC)	rxrpc, kafs

Pour chaque module affecté, vcheck indique s'il est actuellement chargé, intégré au noyau en cours d'exécution, s'il a des traces passées dans les journaux du noyau, s'il a des sockets AF_ALG actives (Copy Fail uniquement), et s'il est déjà mis sur liste noire dans /etc/modprobe.d/.

Avec -fix, vcheck signale l'état initial, écrit un fragment cve-XXXX-XXXXX-disable.conf pour tout module qui n'est pas encore sur liste noire, puis relance les vérifications et signale l'état final. Avec -fix -unload, vcheck tente également de décharger les modules affectés qui étaient chargés avant le correctif, puis utilise l'analyse finale pour vérifier s'ils sont toujours chargés. Avec -fix -rebuild-initramfs, vcheck reconstruit l'initramfs pour le noyau en cours d'exécution (uniquement) après avoir écrit un fragment, de sorte que la liste noire soit intégrée dans l'image de démarrage suivante. Les entrées de noyau plus anciennes conservent leur initramfs d'origine comme solution de repli.

Utiliser -fix uniquement après une exécution sans correction

Exécutez toujours vcheck sans -fix d'abord. Lisez le rapport et confirmez que les modules affectés peuvent être désactivés en toute sécurité sur cet hôte avant de relancer avec -fix. La désactivation de modules noyau dont dépendent des charges de travail légitimes peut affecter les utilisateurs et casser des applications.

En particulier :

• Considérez -fix comme sûr uniquement lorsque aucun des modules affectés n'est actuellement chargé — c'est-à-dire que chaque module est signalé comme mitigé ou module non blacklisté (aucune ligne VULNÉRABLE ou blacklisté mais actuellement chargé). Un module chargé signifie presque toujours que quelque chose sur l'hôte l'utilise activement ; vérifiez cela avant de mettre sur liste noire.
• Les modules IPsec (esp4, esp6, ipcomp4, ipcomp6, xfrm_user) sont nécessaires pour tout déploiement IPsec/strongSwan/WireGuard-over-IPsec/IKE. Les modules ipcomp4/ipcomp6 implémentent la compression de charge utile IPComp et peuvent être auto-négociés dans le cadre d'une SA IPsec même lorsqu'ils ne sont pas explicitement configurés. Ne mettez aucun d'entre eux sur liste noire sur une passerelle VPN, un point de terminaison IPsec ou partout où ip xfrm policy renvoie des règles. Notez que le module framework xfrm_algo n'est intentionnellement pas dans cette liste — selon les directives des fournisseurs (Red Hat, Ubuntu, AWS), bloquer les modules de protocole ESP et IPComp ainsi que l'interface de configuration netlink xfrm_user est suffisant, et blacklister xfrm_algo casserait toutes les autres transformations xfrm pour aucun bénéfice supplémentaire.
• Les modules RxRPC (rxrpc, kafs) sont nécessaires pour tout hôte qui monte des systèmes de fichiers AFS. Leur désactivation cassera ces montages au prochain démarrage.
• algif_aead expose la crypto du noyau via la famille de sockets AF_ALG. Il est rarement utilisé directement par le code applicatif, mais vérifiez en listant les sockets actives (ss -p --af-alg) et en consultant les consommateurs espace utilisateur avant de le blacklister.

Les fragments de liste noire écrits par vcheck ne prennent effet qu'au moment du chargement du module (généralement au prochain démarrage, ou avec modprobe -r <module> lorsque le système est inactif). Un module déjà chargé continuera de fonctionner même après -fix — vcheck le signalera comme blacklisté mais actuellement chargé ; exécutez 'modprobe -r' ou redémarrez. Passer -unload avec -fix demande à vcheck d'exécuter modprobe -r pour les modules affectés chargés après avoir écrit les fragments de liste noire. Utilisez-le uniquement lorsque vous avez confirmé que les modules peuvent être retirés du noyau en cours d'exécution en toute sécurité.

Passer -rebuild-initramfs avec -fix régénère l'initramfs pour le noyau en cours d'exécution uniquement (update-initramfs -u -k $(uname -r) sur Debian/Ubuntu, dracut -f --kver $(uname -r) sur RHEL/Fedora). Les autres noyaux installés conservent leur initramfs existant intact, donc si quelque chose se passe mal après le redémarrage, vous pouvez choisir une entrée de noyau plus ancienne dans le menu de démarrage et récupérer. Les futures installations de noyau reconstruisent leur propre initramfs à partir de l'état actuel de /etc/modprobe.d/, donc la liste noire se propage automatiquement sans relancer vcheck. Si ni update-initramfs ni dracut n'est présent (par exemple Arch, Alpine, images immuables), vcheck émet un avertissement et continue — reconstruisez manuellement avec l'outil de la distribution avant de redémarrer.

La reconstruction peut prendre plusieurs minutes (surtout dracut sur les hôtes avec de nombreux pilotes), ce qui dépasserait le -command-timeout de diagnostic. Elle s'exécute sous son propre -initramfs-timeout (par défaut 10m) de sorte que la reconstruction dispose de l'espace nécessaire tandis que les vérifications rapides conservent leur budget serré. Augmentez -initramfs-timeout pour le matériel lent, ou passez 0 pour désactiver complètement le délai d'attente. Pendant les commandes distantes de longue durée, vcheck envoie des requêtes keepalive SSH toutes les 30s par défaut pour éviter que les temporisateurs d'inactivité NAT/pare-feu ne coupent la connexion. Ajustez cela avec -ssh-keepalive, ou passez 0 pour le désactiver.

Installation

Homebrew (macOS) :

brew install --cask krisiasty/tap/vcheck

Binaires pré-compilés pour Linux, macOS et Windows sont publiés sur la page des versions.

Depuis les sources (nécessite Go 1.26+) :

go install github.com/krisiasty/vcheck@latest

Utilisation

vcheck -host HOST [flags]