> ## Documentation Index
> Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Copy Fail (CVE-2026-31431) : élévation locale de privilèges dans le noyau Linux

> Une faille critique du sous-système cryptographique du noyau Linux permet à un utilisateur local de devenir root. Analyse, périmètre, mitigation.

*Publié le 1 mai 2026*

<Warning>
  **CVE-2026-31431 — surnommée "Copy Fail".** Bug d'élévation locale de privilèges présent dans la quasi-totalité des noyaux Linux récents. Si votre serveur fait tourner du code tiers ou expose un accès shell, traitez la mitigation comme prioritaire.
</Warning>

## Le problème en deux phrases

La faille loge dans le sous-système cryptographique du noyau Linux, exposé via l'interface **AF\_ALG** (module `algif_aead`). Elle permet à du code s'exécutant localement avec des droits limités d'écrire en zone noyau et d'en sortir avec les privilèges `root`.

Concrètement, deux scénarios d'exploitation ressortent :

* **Sortie d'un compte utilisateur vers root** sur un serveur classique.
* **Évasion de conteneur** vers le nœud hôte sur Docker ou Kubernetes — le périmètre d'isolation des pods s'effondre.

L'attaquant a besoin d'un point d'appui local préalable (compte utilisateur, pod, code embarqué dans une dépendance, etc.). Sans cela, la faille n'est pas exploitable à distance.

## Évaluer son exposition

Plutôt qu'une criticité absolue, la bonne grille de lecture est : **qui peut exécuter du code chez vous ?**

| Profil                                                                                                                                   | Exposition   | Réaction                                              |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ----------------------------------------------------- |
| VPS dédié à votre application, sans tiers, code maîtrisé                                                                                 | Faible       | Attendre le correctif noyau, planifier la mise à jour |
| VPS hébergeant plusieurs clients, plusieurs comptes shell, ou exécutant du code non audité (CI partagée, plugins, runtimes utilisateurs) | **Critique** | Mitiger immédiatement, puis patcher                   |
| Cluster Kubernetes où vous orchestrez des pods de tiers ou des workloads dynamiques                                                      | **Critique** | DaemonSet de mitigation sur tous les nœuds            |

## Mitigation immédiate

Le correctif définitif passera par une mise à jour du noyau. En attendant qu'il atterrisse dans votre distribution, on désactive le module incriminé. L'opération est réversible et n'impacte pas la grande majorité des charges applicatives.

### Sur Debian, Ubuntu et dérivés

```bash theme={null}
# Bloque le rechargement automatique au prochain démarrage
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

# Décharge le module déjà résident en mémoire
sudo rmmod algif_aead 2>/dev/null || true
```

### Sur RHEL, AlmaLinux, Rocky Linux, CentOS et Fedora

L'approche est légèrement différente : on passe par GRUB pour neutraliser le module dès l'initialisation du noyau.

```bash theme={null}
sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
sudo reboot
```

### Sur un cluster Kubernetes

Si vous orchestrez vos VPS via Kubernetes, propagez la mitigation sur tous les nœuds avec un DaemonSet privilégié. Le pod `pause` à la fin évite que le DaemonSet termine et soit relancé en boucle après le `initContainer`.

```yaml theme={null}
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-algif-aead
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: disable-algif-aead
  template:
    metadata:
      labels:
        app: disable-algif-aead
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: disable-algif-aead
          image: alpine:3.23
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
              rmmod algif_aead 2>/dev/null || true
          volumeMounts:
            - name: modprobe-d
              mountPath: /etc/modprobe.d
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.10
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
      volumes:
        - name: modprobe-d
          hostPath:
            path: /etc/modprobe.d
```

## Vérifier que la mitigation est active

Une vérification rapide après application :

```bash theme={null}
# Le module ne doit plus apparaître
lsmod | grep algif_aead

# Et toute tentative de chargement doit échouer
sudo modprobe algif_aead 2>&1
# attendu : "install /bin/false algif_aead" suivi de l'échec
```

Si `lsmod` ne renvoie rien et que `modprobe` échoue, la mitigation est en place.

## Annuler la mitigation

Si un service spécifique exploite l'API `AF_ALG` du noyau (ce qui reste rare hors usages cryptographiques de bas niveau), vous pouvez réactiver le module :

```bash theme={null}
sudo rm /etc/modprobe.d/disable-algif.conf
sudo modprobe algif_aead
```

Sur RHEL et dérivés, retirer aussi le paramètre noyau :

```bash theme={null}
sudo grubby --update-kernel=ALL --remove-args=initcall_blacklist=algif_aead_init
sudo reboot
```

## Et après ?

Surveillez les bulletins de votre distribution — le correctif noyau est la cible finale, la désactivation du module n'est qu'un palliatif. Pour toute question technique, ouvrez un ticket depuis votre [espace client OnetSolutions](https://onetsolutions.net).