CVE-2026-31431 — « Copy Fail »

Élévation de privilèges locale dans le sous-système crypto algif_aead du noyau Linux.

Vue d'ensemble

CVE-2026-31431, surnommée « Copy Fail », est un bug logique dans le modèle cryptographique authencesn du noyau Linux (algif_aead). Il permet à un utilisateur local non privilégié d'effectuer une écriture contrôlée de 4 octets dans le cache de pages de n'importe quel fichier lisible, ce qui peut être exploité pour modifier un binaire setuid et obtenir les droits root.

• CVSS : 7,8 (Élevé)
• Affecté : Tous les noyaux Linux grand public distribués depuis 2017
• Exploit : Un script Python de 732 octets — aucune condition de course, aucun décalage spécifique au noyau
• Correctif : Commit principal a664bf3d603d

Chronologie

Matrice d'impact

L'exploit nécessite deux éléments : une socket AF_ALG (autorisée par défaut dans tous les profils seccomp) et un binaire setuid (ex. /usr/bin/su). La principale mesure d'atténuation est allowPrivilegeEscalation: false — cela définit le drapeau no_new_privs du noyau Linux via prctl(PR_SET_NO_NEW_PRIVS, 1), ce qui amène le noyau à ignorer les bits setuid/setgid lors de execve(). Comme l'exploit repose sur l'exécution d'un binaire setuid modifié, cela bloque l'étape finale d'élévation.

Ce n'est pas une fonctionnalité spécifique à OpenShift — cela fonctionne de la même manière sur Kubernetes standard (Pod Security Standards Restricted), Docker (--security-opt no-new-privileges) et Podman. OpenShift l'applique simplement par défaut via le SCC restricted-v2, tandis que les autres plateformes nécessitent une configuration explicite.

RHEL 8 / RHEL 9

RHEL 8 et RHEL 9 sont livrés avec des noyaux contenant le code vulnérable. Un utilisateur local non privilégié disposant d'un accès shell peut exploiter cette faille pour obtenir root. Appliquez le correctif immédiatement.

yum updateinfo list cves CVE-2026-31431
yum update kernel

OpenShift (4.x)

OpenShift fonctionne sur RHCOS, qui est livré avec le noyau vulnérable. L'impact pratique dépend des Security Context Constraints (SCC) de la charge de travail.

Les charges de travail standard utilisant le SCC restricted-v2 par défaut ne sont pas exploitables car allowPrivilegeEscalation: false est appliqué.

Les pods fonctionnant avec des SCC élevés (anyuid, privileged, ou des SCC personnalisés autorisant allowPrivilegeEscalation: true) sont vulnérables. Cela inclut généralement :

• Les pods de build CI/CD (agents Jenkins, Tekton avec SCC personnalisés)
• Les applications héritées nécessitant anyuid
• Les pods d'infrastructure (supervision, journalisation, stockage)

L'accès direct aux nœuds (ex. via oc debug node/) est toujours vulnérable — élévation de privilèges locale standard, sans isolation de conteneur.

Tests

Un pod de test est fourni pour vérifier si les prérequis de l'exploit sont réunis dans votre cluster. Il ne tente pas d'exploiter la vulnérabilité — il vérifie uniquement :

1. Une socket AF_ALG peut-elle être créée ? (surface d'attaque du noyau accessible)
2. no_new_privs est-il défini ? (bloque l'élévation setuid)
3. Des binaires setuid sont-ils présents dans l'image du conteneur ?
4. Version du noyau du nœud sous-jacent

Utilisation (Pod)

oc apply -f test-pod.yaml
oc logs cve-2026-31431-check
oc delete -f test-pod.yaml

Utilisation (Deployment)

Utilisez la variante Deployment pour tester sur plusieurs nœuds en augmentant les réplicas ou en utilisant l'anti-affinité de pods :

oc apply -f test-deployment.yaml
oc logs -l app=cve-2026-31431-check
oc delete -f test-deployment.yaml

Codes de sortie

Résultat attendu sur OpenShift par défaut

Sur un cluster OpenShift standard avec le SCC restricted-v2, vous devriez voir le code de sortie 1 (partiellement exposé) : la socket AF_ALG peut être créée (le seccomp RuntimeDefault ne la bloque pas), mais no_new_privs empêche l'étape d'élévation setuid. Le PoC publié ne fonctionnera pas, mais la vulnérabilité au niveau du noyau reste accessible — l'application du correctif est recommandée.

Atténuation

1. Appliquer le correctif au noyau (P0)

C'est le seul correctif complet. Mettez à jour le noyau sur tous les nœuds et redémarrez.

Pour OpenShift, mettez à jour vers une version RHCOS incluant le correctif et effectuez un redémarrage progressif des nœuds.

2. Désactiver le module algif_aead (solution temporaire)

Si algif_aead est compilé en tant que module chargeable (CONFIG_CRYPTO_USER_API_AEAD=m) :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Cela ne fonctionne PAS si algif_aead est intégré (=y), ce qui est le cas sur RHCOS. Vérifiez avec :

modinfo algif_aead 2>&1 | grep builtin
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

3. Bloquer AF_ALG via seccomp (OpenShift)

Si le module du noyau est intégré, la seule atténuation pré-correctif pour les conteneurs consiste à bloquer l'appel système socket(AF_ALG, ...) via un profil seccomp personnalisé.

Déployer le profil seccomp via MachineConfig

Créez la MachineConfig pour placer le profil sur tous les nœuds (répétez avec role: master pour les nœuds du plan de contrôle) :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-seccomp-deny-af-alg
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /var/lib/kubelet/seccomp/deny-af-alg.json
          mode: 0644
          contents:
            source: data:application/json;charset=utf-8;base64,ewogICJkZWZhdWx0QWN0aW9uIjogIlNDTVBfQUNUX0FMTE9XIiwKICAic3lzY2FsbHMiOiBbCiAgICB7CiAgICAgICJuYW1lcyI6IFsic29ja2V0Il0sCiAgICAgICJhY3Rpb24iOiAiU0NNUF9BQ1RfRVJSTk8iLAogICAgICAiYXJncyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaW5kZXgiOiAwLAogICAgICAgICAgInZhbHVlIjogMzgsCiAgICAgICAgICAib3AiOiAiU0NNUF9DTVBfRVEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9

Le contenu base64 se décode en :

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Remarque : L'application d'une MachineConfig déclenche un redémarrage progressif des nœuds.

Référencer le profil dans les spécifications de pods

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: deny-af-alg.json

Alternative à l'échelle du cluster

Pour protéger tous les conteneurs sans modifier les spécifications de pods, remplacez le profil seccomp par défaut de CRI-O (/etc/crio/seccomp.json) via MachineConfig en ajoutant la règle de filtrage AF_ALG au profil existant.

4. Auditer vos SCC

Identifiez les pods fonctionnant avec des privilèges élevés :

# Trouver les pods n'utilisant pas restricted-v2
oc get pods -A -o json | jq -r '
  .items[] |
  select(.metadata.annotations["openshift.io/scc"] != "restricted-v2") |
  "\(.metadata.namespace)/\(.metadata.name) → \(.metadata.annotations["openshift.io/scc"])"
'

Ce sont les pods où la chaîne d'exploitation complète fonctionne. Priorisez l'application du correctif ou l'atténuation seccomp pour les nœuds exécutant ces charges de travail.

Impact de la désactivation d'AF_ALG

Le blocage des sockets AF_ALG a un impact négligeable sur la plupart des charges de travail. Les éléments suivants ne sont pas affectés :

• dm-crypt / LUKS
• kTLS
• IPsec
• OpenSSL / GnuTLS (builds standard)

Seules les applications explicitement configurées pour utiliser le moteur afalg d'OpenSSL seront affectées.

Références

• Copy Fail — Page du projet
• Red Hat CVE-2026-31431
• NVD — CVE-2026-31431
• RuntimeDefault ne bloque pas AF_ALG (juliet.sh)
• Xint — Analyse de Copy Fail
• The Register — Défaut dans le code cryptographique Linux