CVE-2026-31431 (« Copy Fail ») — Recette d'atténuation Ansible

Détectez et appliquez l'atténuation par ligne de commande du noyau pour CVE-2026-31431 (« Copy Fail ») sur un parc Debian / Ubuntu / famille RHEL à l'aide d'Ansible.

La CVE est une faille d'élévation de privilèges locale dans l'interface algif_aead AF_ALG du noyau Linux. Tout utilisateur local non privilégié — y compris les comptes de service comme www-data, mysql, ou les processus à l'intérieur d'une application web compromise par RCE — peut l'enchaîner jusqu'à root en quelques appels système. Le bug affecte toutes les principales distributions publiées depuis 2017.

Ce que fait cette recette

Détecte quels hôtes ne disposent pas de l'atténuation. Lecture seule par défaut.
Applique l'atténuation universelle — ajoute initcall_blacklist=algif_aead_init à la ligne de commande du noyau — lorsqu'elle est invoquée avec -e apply_mitigation=true.
Ne redémarre jamais automatiquement. Les redémarrages relèvent de l'opérateur.

La liste noire de la ligne de commande du noyau fonctionne sur les deux configurations intégrées (famille RHEL) et modulaires (Debian/Ubuntu), ce que la solution souvent citée modprobe blacklist algif_aead ne fait pas.

Comment fonctionne l'atténuation

algif_aead_init() est la fonction du noyau qui enregistre l'algorithme aead AF_ALG avec le sous-système de sockets crypto au démarrage. Le paramètre de ligne de commande initcall_blacklist=algif_aead_init demande au noyau d'ignorer cet initcall. Le code vulnérable est toujours présent dans le binaire du noyau, mais socket(AF_ALG, ..., "aead") renvoie ENOENT, donc le premier appel système de l'exploit échoue. Aucune surface accessible, aucune élévation de privilèges.

Une fois que les fournisseurs publient des noyaux corrigés et que vous redémarrez dessus, l'atténuation n'est plus nécessaire et peut être supprimée.

Démarrage rapide

# 1. Détection (lecture seule) — produit un rapport d'état par hôte
ansible-playbook -i inventory check_cve_2026_31431.yml

# 2. Préparation de l'atténuation sur un seul hôte d'abord (pas de redémarrage automatique)
ansible-playbook -i inventory --limit <ip-or-host> \
  -e apply_mitigation=true check_cve_2026_31431.yml

# 3. Redémarrez cet hôte via votre mécanisme habituel

# 4. Re-détection ; confirmez « Mitigation active: yes »

# 5. Déployez sur le reste du parc par lots

Le rapport d'un hôte vulnérable ressemble à ceci :

═══════════════════════════════════════════
Host:               192.168.1.42
Distro:             Ubuntu 24.04
Kernel:             6.8.0-60-generic
Mitigation active:  no
Mitigation staged:  no
═══════════════════════════════════════════
⚠️  192.168.1.42: CVE-2026-31431 mitigation is NOT active.

Revenir en arrière après la publication d'un noyau corrigé

Hors du périmètre de cette recette. Commandes manuelles :

# Debian / Ubuntu
sudo sed -i 's/ initcall_blacklist=algif_aead_init//' /etc/default/grub
sudo update-grub
sudo reboot

# Famille RHEL
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Comportement sans échec

Le chemin de détection est strictement en lecture seule (uname, lecture de /proc/cmdline, lecture de /etc/default/grub, grubby --info=ALL). Les sondes utilisent failed_when: false afin qu'une sortie inattendue n'interrompe jamais le play. ignore_unreachable: true signifie que les hôtes inaccessibles reçoivent un avertissement clair « UNREACHABLE — treat as VULNERABLE » au lieu de faire échouer l'exécution.

Le chemin d'application est encapsulé dans block/rescue afin qu'un seul mauvais hôte n'arrête jamais le reste. La modification de grub est idempotente et conditionnée par mitigation_staged afin que les ré-exécutions soient sans effet.

Tests

bash tests/run-checks.sh all

Étapes : lint (yamllint + ansible-lint) → syntax (ansible-playbook --syntax-check) → dry-run (exécute le playbook en mode --check contre localhost avec -c local, les chemins de détection et d'application). Le même script est invoqué par la matrice GitHub Actions sur les conteneurs debian:12, ubuntu:22.04, ubuntu:24.04 et almalinux:9 à chaque push et pull request.

Ce que le dry-run ne vérifie pas :

Il ne modifie pas grub, n'exécute pas update-grub et ne déclenche pas de redémarrage.
/proc/cmdline dans un conteneur CI affiche la ligne de commande de l'hôte d'exécution, pas celle du conteneur, donc mitigation_active dans la sortie CI n'a pas de sens. La CI prouve que le playbook s'exécute proprement ; elle ne prouve pas qu'un hôte est atténué.

Voir tests/README.md pour plus de détails.

Sources

Crédits

Vulnérabilité découverte par Taeyang Lee (Theori) et transformée en une chaîne d'exploitation complète par la Xint Code Research Team, qui mérite le crédit d'avoir attiré l'attention de la communauté de la sécurité. Cette recette automatise simplement l'atténuation qu'ils ont recommandée.

Licence

Beerware. Voir LICENSE. En résumé : faites-en ce que vous voulez ; si nous nous rencontrons un jour, offrez-moi une bière.

Mainteneur

AESTECHNO — Hugues Orgitello — bureau d'études en électronique, Montpellier, France.