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

Table of Contents

CVE Deep Dives - This article is part of a series.

Part : This Article

Part : CVE-2023-50564 : analyse technique de l'upload arbitraire dans Pluck CMS

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
Exploitation connue: ajoutée au catalogue CISA KEV le 1er mai 2026, avec une échéance fédérale fixée au 15 mai 2026
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.

Du chemin de copie à l’élévation de privilèges
#

Le point subtil est le changement de sphère : des buffers contrôlés depuis l’espace utilisateur sont traités par une primitive cryptographique dans le noyau, tandis que les pages source et destination proviennent de mappings différents. La logique in-place tentait pourtant de les manipuler comme s’il était sûr de réutiliser le même emplacement.

Le PoC public matérialise cette primitive en combinant une socket AF_ALG, des messages AEAD et splice() pour altérer les pages associées à un binaire privilégié, puis déclencher son exécution. Le schéma ci-dessous représente ce chemin de démonstration, pas une recette d’exploitation générique.

flowchart LR User["Processus local non privilégié"] File["Mapping d'un binaire privilégié"] Socket["Socket AF_ALG
algif_aead"] Copy["sendmsg et splice
buffers et scatterlists"] Bug["Chemin in-place incohérent
entre mappings distincts"] Cache["Altération des pages
du fichier ciblé"] Exec["Exécution du binaire modifié"] Root["Contexte root"] User --> File User --> Socket File --> Copy Socket --> Copy Copy --> Bug Bug --> Cache Cache --> Exec Exec --> Root

Conditions d’exploitation
#

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

l’attaquant a déjà un shell local non root (PR:L)
il peut invoquer l’API AF_ALG
il déclenche la primitive vulnérable côté kernel
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

Les portes que l’attaquant doit franchir
#

Condition	Pourquoi elle compte	Question de triage
Exécution locale non privilégiée	la vulnérabilité n’est pas déclenchée directement par le réseau	quels comptes, jobs ou conteneurs peuvent exécuter du code ?
Noyau réellement vulnérable	un numéro de paquet seul ne suffit pas à cause des backports	quel noyau est actuellement booté et quel correctif vendor contient-il ?
Chemin `AF_ALG` atteignable	le PoC dépend de l’interface crypto exposée à l’espace utilisateur	observe-t-on la création de sockets `AF_ALG` par des processus inattendus ?
Cible privilégiée exécutable	l’élévation nécessite de transformer la primitive en effet durable	les binaires sensibles sont-ils surveillés par FIM ou mesurés par IMA ?
Absence de confinement efficace	MAC, sandboxing et réduction des privilèges peuvent limiter la chaîne	AppArmor, SELinux, seccomp ou la politique du runtime bloquent-ils une étape ?

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
#

La détection doit couvrir toute la chaîne, car la primitive noyau peut ne pas ressembler à une écriture de fichier classique. Un capteur isolé peut donc manquer l’événement alors qu’un autre observe sa conséquence.

flowchart LR A["Processus non privilégié"] --> B["Socket AF_ALG inhabituelle"] B --> C["Séquence sendmsg et splice"] C --> D["Contenu d'un binaire sensible modifié"] D --> E["Exécution privilégiée"] E --> F["Shell ou action root"] B -.-> S1["eBPF ou EDR"] C -.-> S2["Télémétrie syscall"] D -.-> S3["FIM, IMA, contrôle d'intégrité"] E -.-> S4["auditd et journal d'authentification"] F -.-> S5["Corrélation identité-processus"]

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)

Source	Signal fort	Limite
eBPF / EDR noyau	socket famille 38 (`AF_ALG`) suivie de `sendmsg`, `splice` et exécution sensible	`AF_ALG` peut être légitime sur certains workloads crypto
FIM / IMA	hash ou mesure d’un binaire privilégié qui change hors gestionnaire de paquets	une vérification périodique peut arriver après l’élévation
auditd	transition utilisateur vers root et exécution de `su` incohérente	la primitive elle-même peut ne pas produire une écriture classique
journaux de paquets	version corrigée installée puis noyau réellement redémarré	le paquet installé ne prouve pas que le noyau corrigé est booté
SIEM	corrélation processus, identité, intégrité et chronologie	dépend de la synchronisation temporelle et de la qualité des capteurs

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
#

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

Références
#

Sources officielles et techniques:

MITRE CVE Record: https://cveawg.mitre.org/api/cve/CVE-2026-31431
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-31431
Linux CVE announce: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/
PoC public: https://github.com/theori-io/copy-fail-CVE-2026-31431
Technical writeup (éditeur PoC): https://xint.io/blog/copy-fail-linux-distributions
Ubuntu advisory: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
Red Hat advisory page: https://access.redhat.com/security/cve/cve-2026-31431#cve-details-mitigation

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 : analyse technique de l'upload arbitraire dans Pluck CMS

TL;DR#

Contexte et chronologie#

Composants techniques concernés#

Cause racine (root cause)#

Du chemin de copie à l’élévation de privilèges#

Conditions d’exploitation#

Les portes que l’attaquant doit franchir#

Versions affectées et versions corrigées#

PoC public et fiabilité#

Impact sécurité#

Confidentialité#

Intégrité#

Disponibilité#

Conteneurs et cloud#

Détection - approche défensive pratique#

1) Inventaire et exposition#

2) Triage rapide des hôtes Linux#

3) Indicateurs comportementaux#

4) Corrélation SOC#

Mitigation et remédiation#

Priorité 0: patch kernel#

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

Validation post-remédiation#

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

Étape 1 - Identification#

Étape 2 - Containment#

Étape 3 - Eradication#

Étape 4 - Recovery#

Étape 5 - Lessons learned#

Mapping ATT&CK (indicatif)#

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

Références#

Note éthique#