Description de la vulnérabilité

Cause de la vulnérabilité

Le module de chiffrement du noyau Linux authesn a introduit en 2017 une optimisation en place (in-place) pour les opérations AEAD (chiffrement authentifié), qui a conduit, dans certaines conditions, à ce que des pages en lecture seule du cache de pages (page cache) puissent être placées par erreur dans une liste de segments (scatterlist) de destination inscriptible. Un attaquant, via l'API de chiffrement du noyau exposée par les sockets AF_ALG, combinée à l'appel système splice(), exploite ce défaut logique pour réaliser une écriture arbitraire de 4 octets dans le cache de pages de binaires setuid (tels que /usr/bin/su), falsifiant ainsi la logique du programme et obtenant un shell root.

L'ensemble du processus d'exploitation est une logique linéaire, sans fenêtre de compétition (race window), sans décalages spécifiques au noyau, et sans préinstallation d'outils particuliers.

Impact de la vulnérabilité

• Élévation de privilèges locale vers root : tout compte utilisateur local ordinaire peut être élevé sans condition vers root.

• Évasion de conteneur : dans les environnements Kubernetes / conteneurs, le cache de pages est partagé avec l'hôte ; un attaquant à l'intérieur d'un conteneur peut franchir la frontière du conteneur, compromettant le nœud hôte ainsi que les autres locataires du même nœud.

• Compromission des environnements CI/CD : les environnements CI exécutant du code non fiable, tels que GitHub Actions, GitLab Runner, Jenkins Agent, permettent à un attaquant d'obtenir directement les privilèges root de la machine hôte du Runner via une PR malveillante.

• Environnements cloud multi-locataires : les services cloud exécutant du code utilisateur, tels que Notebook, Serverless, sandbox d'agents, permettent à un locataire d'être élevé vers root sur la machine hôte.

• Vulnérabilité persistante depuis près de dix ans : le code problématique a été introduit en 2017, et toutes les distributions Linux depuis lors sont affectées.

Versions affectées

Toutes les versions du noyau Linux construites entre 2017 et avant la publication du correctif, couvrant :

Solution

Correctif de mise à niveau

Mettez à niveau vers une version du noyau incluant le commit mainline a664bf3d603d ; les principales distributions publient progressivement des versions corrigées :

# Ubuntu / Debian
apt update && apt upgrade linux-image-$(uname -r)
# RHEL / CentOS / Rocky / Alma
dnf update kernel
# Amazon Linux
yum update kernel
# SUSE
zypper update kernel-default

Après la mise à niveau, redémarrez le système pour activer le nouveau noyau, puis vérifiez avec la commande suivante que le commit de correctif est inclus :

grep -r "a664bf3d603d" /proc/version 2>/dev/null || uname -r 
# Vérifie si le commit de correctif est inclus ou compare avec le numéro de version du correctif dans l'annonce officielle de la distribution

Atténuation temporaire

La désactivation du module du noyau algif_aead bloque le chemin d'exploitation de la vulnérabilité :

# Désactivation permanente (effective après redémarrage)
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# Déchargement immédiat (effectif pour la session en cours)
rmmod algif_aead 2>/dev/null || true

Évaluation de l'impact de la désactivation d'algif_aead :

• Sans impact : dm-crypt/LUKS, kTLS, IPsec/XFRM, constructions par défaut d'OpenSSL/GnuTLS/NSS, SSH, chiffrement du trousseau de clés du noyau — ces composants utilisent directement l'API de chiffrement du noyau, sans passer par AF_ALG.

• Impact possible : OpenSSL avec moteur afalg explicitement activé, certains chemins de déchargement de chiffrement embarqués, applications liées directement aux sockets aead/skcipher/hash. Vous pouvez vérifier si des processus utilisent actuellement AF_ALG sur le système avec lsof | grep AF_ALG ou ss -xa.