↓Skip to main content
Raizen | Blog

CVE-2026-31431 (Copy Fail) - Linux Kernel LPE Deep Dive

·5 mins
Post CVE Linux Kernel Privilege Escalation AF_ALG Algif_aead Copy Fail Defensive Security
Rai2en
Author
Rai2en
Breaking things to understand them.
Table of Contents
CVE Deep Dives - This article is part of a series.
Part : This Article
Part : CVE-2023-50564 - Pluck CMS v4.7.18

TL;DR
#

CVE-2026-31431, surnommée Copy Fail, est une élévation de privilèges locale (LPE) dans le noyau Linux, liée au sous-système crypto AF_ALG et plus précisément à algif_aead.

  • Type: Local Privilege Escalation
  • Score NVD: CVSS 3.1 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
  • Surface: kernels Linux impactés depuis une régression introduite par un commit précis
  • Exploitabilité: des PoC publics existent
  • Risque business: un utilisateur local non privilégié peut obtenir root

Contexte et chronologie
#

D’après MITRE/NVD, la vulnérabilité est publiée fin avril 2026 et documente un correctif de logique dans le code crypto du noyau.

Le message de fix indique explicitement:

  • crypto: algif_aead - Revert to operating out-of-place
  • Revert majoritaire du commit fautif 72548b093ee3 (sauf copie des données associées)

En clair: une optimisation “in-place” dans le chemin AEAD a ajouté de la complexité et introduit une condition dangereuse de copie/mapping mémoire.

Composants techniques concernés
#

Chemins de code mentionnés par le CNA Linux:

  • crypto/af_alg.c
  • crypto/algif_aead.c
  • crypto/algif_skcipher.c
  • include/crypto/if_alg.h

Sous-système concerné:

  • AF_ALG (interface crypto user space <-> kernel)
  • algif_aead (AEAD: authenticated encryption with associated data)

Cause racine (root cause)
#

Le correctif upstream indique un retour vers un mode de fonctionnement out-of-place pour algif_aead, car le mode in-place ne donnait pas de bénéfice ici et augmentait fortement la complexité de gestion des buffers/scatterlists.

Effets observés dans le patch de fix:

  • simplification de la logique de comptage/pull des TSGL
  • suppression d’un traitement offset complexe
  • alignement de la construction des SGL sur un chemin plus simple et plus sûr

Cette simplification retire le comportement qui ouvrait la voie à une corruption logique exploitable dans certaines conditions.

Conditions d’exploitation
#

Cette CVE est une LPE locale. Le scénario type:

  1. l’attaquant a déjà un shell local non root (PR:L)
  2. il peut invoquer l’API AF_ALG
  3. il déclenche la primitive vulnérable côté kernel
  4. il obtient une écriture/altération menant à l’élévation root

Remarque importante:

  • ce n’est pas une RCE distante “one-shot”
  • mais dans un contexte post-compromission, multi-tenant, CI runner, container breakout local, ou bastion partagé, l’impact est critique

Versions affectées et versions corrigées
#

Les données CNA/NVD indiquent une plage impactée démarrant au commit fautif 72548b093ee38a6d4f2a19e6ef1948ae05c181f7.

Versions explicitement marquées comme corrigées (branches stables):

  • 5.10.254+
  • 5.15.204+
  • 6.1.170+
  • 6.6.137+
  • 6.12.85+
  • 6.18.22+
  • 6.19.12+

Toujours vérifier:

  • le noyau effectivement booté (uname -r)
  • le changelog de votre distribution (backports fréquents)

PoC public et fiabilité
#

Un PoC public est référencé dans les sources CVE:

  • https://github.com/theori-io/copy-fail-CVE-2026-31431

Le script PoC public montre:

  • utilisation de socket AF_ALG
  • exploitation du chemin aead/authencesn(...)
  • tentative d’altération d’un binaire sensible, puis élévation

Exemples de distributions testées annoncées par l’auteur du PoC:

  • Ubuntu 24.04 LTS
  • Amazon Linux 2023
  • RHEL 10.1
  • SUSE 16

Impact sécurité
#

Confidentialité
#

Un attaquant root peut lire des secrets système (tokens, clés privées, credentials applicatifs).

Intégrité
#

Modification de fichiers binaires/config sensibles, persistence, désactivation d’agents sécurité.

Disponibilité
#

Risque de sabotage, chiffrement malveillant, arrêt de services critiques.

Conteneurs et cloud
#

Même si l’exploit est local, les environnements cloud/containers sont fortement exposés si:

  • hôte non patché
  • privilèges locaux déjà obtenus dans un conteneur
  • contrôles kernel insuffisants

Détection - approche défensive pratique
#

1) Inventaire et exposition
#

Lister kernels:

uname -r
cat /etc/os-release

Sur flotte:

  • CMDB + scanner vulnérabilités
  • corrélation OS/kernel/package advisory

2) Triage rapide des hôtes Linux
#

Vérifier présence de AF_ALG et activité anormale:

grep AF_ALG /proc/net/protocols || true

Observer processus ayant créé des sockets AF_ALG (eBPF/auditd/EDR selon outillage).

3) Indicateurs comportementaux
#

Chercher:

  • exécutions Python inhabituelles sur serveurs prod
  • accès/écriture suspects sur binaires critiques (/usr/bin/su, etc.)
  • séquences “local user -> root” anormales
  • crash/artefacts kernel autour des opérations crypto socket

4) Corrélation SOC
#

Règles utiles:

  • alerte sur exécution de PoC connus/hashs/YARA
  • alerte sur spawn root depuis utilisateur applicatif sans chaîne sudo légitime
  • alerte sur modifications de binaires système (FIM)

Mitigation et remédiation
#

Priorité 0: patch kernel
#

Appliquer les kernels corrigés fournis par la distribution (ou équivalent backport vendor).

Toujours valider après reboot:

uname -r

Durcissement court terme (si patch non immédiat)
#

Mesures temporaires de réduction du risque:

  • réduire l’accès shell local non nécessaire
  • renforcer segmentation des comptes de service
  • durcir permissions sur environnements partagés
  • activer contrôles EDR/FIM sur binaires système
  • minimiser capacités/privileges dans conteneurs

Important: ces mesures ne remplacent pas le patch noyau.

Validation post-remédiation
#

Checklist:

  • kernel corrigé déployé et booté
  • aucun hôte restant sur version vulnérable
  • surveillance renforcée 7 jours
  • revue des logs d’escalade locale sur fenêtre rétroactive
  • IOC de PoC/artefacts recherchés

Runbook SOC/IR (prêt à l’emploi)
#

Étape 1 - Identification
#

  • confirmer version kernel et exposition CVE
  • qualifier si accès local attaquant possible

Étape 2 - Containment
#

  • isoler hôtes suspects
  • suspendre comptes compromis
  • bloquer jobs/containers non essentiels si nécessaire

Étape 3 - Eradication
#

  • patch kernel
  • rotation secrets potentiellement exposés
  • suppression persistence/rootkits

Étape 4 - Recovery
#

  • redémarrage contrôlé
  • validation services
  • monitoring renforcé

Étape 5 - Lessons learned
#

  • délai patching kernel
  • gaps de visibilité sur LPE locales
  • amélioration hardening + détection

Mapping ATT&CK (indicatif)
#

  • Privilege Escalation: T1068 (Exploitation for Privilege Escalation)
  • Defense Evasion/Persistence possibles selon post-exploitation

Ce qu’il faut retenir pour les équipes défensives
#

  1. Les LPE kernel restent un accélérateur majeur post-compromission.
  2. Le patch management noyau doit être traité comme une urgence de prod.
  3. La détection doit couvrir la transition utilisateur non privilégié -> root.
  4. Les environnements container/cloud ne sont pas immunisés à ce type de faille locale.

Références
#

Sources officielles et techniques:

Stable fix commits référencés par la CVE:

Note éthique
#

Ce contenu est fourni pour la défense, la remédiation et l’amélioration de la sécurité. Tester uniquement dans des environnements autorisés.

CVE Deep Dives - This article is part of a series.
Part : This Article
Part : CVE-2023-50564 - Pluck CMS v4.7.18