Une faille du noyau Linux CIFSwitch permet l'accès aux privilèges root en local sur cifs-utils

28 mai 2026 – 7 min de lecture Chris DeMars, chargé de promotion des développeurs senior

En bref

Description : une nouvelle faille de sécurité sous Linux permettant l'escalade de privilèges en local, baptisée « CIFSwitch », exploite l'absence de vérification au niveau du noyau concernant les descriptions de clés cifs.spnego, combinée à la confiance que l'assistant cifs.upcall de l'espace utilisateur accorde à ces descriptions. Il en résulte l'obtention d'un shell root à partir de n'importe quel compte local non privilégié sur les hôtes affectés. Cette faille dans le code du noyau est présente depuis 2007. Aucun numéro CVE n'avait encore été attribué au moment de la publication.

Impact : une démonstration publique de faisabilité réalisée par Asim Manizada permet à n'importe quel utilisateur local sans privilèges d'accéder de manière fiable au niveau root sur les systèmes remplissant les conditions préalables à l'exploitation de la faille. L'auteur a confirmé que la vulnérabilité concernait environ 30 combinaisons de distributions et d'éditions.

Statut : Manizada a révélé la faille CIFSwitch sur oss-security le 28 mai 2026, à l'issue d'une période d'embargo imposée par les distributions Linux. Le bug a été signalé aux responsables du noyau/CIFS le 16 mai, et le correctif en amont (commit 3da1fdf4efbc) est accessible au public depuis plus d'une semaine et est en attente d'intégration dans la version stable.

Gravité : confirmée dès l'installation sur AlmaLinux 9.7, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint 21/22, Kali 2021 à 2026 en mode sans interface graphique, et SLES 15 SP7/SAP. Vulnérable lorsque cifs-utils est installé manuellement sur Debian 11/12/13, Ubuntu 18/20/22/24.04, openSUSE Leap 15.6, Oracle Linux 8/9 et Amazon Linux 2023.

Pourquoi est-ce important ? Cette faille cible un utilitaire privilégié installé par défaut, ne nécessite qu'un shell local sans privilèges et dispose d'un PoC public fonctionnel. Tout hôte Linux sur lequel un attaquant sans privilèges peut exécuter du code doit être considéré comme exposé à un risque immédiat si cifs-utils et la règle cifs.spnego par défaut sont présents, si le module noyau CIFS est disponible, si les espaces de noms sans privilèges sont activés et si la politique LSM ne bloque pas le pivot.

Procédez ainsi dès maintenant : si votre hôte ne monte pas les partages SMB authentifiés par Kerberos (ce qui est le cas de la plupart des serveurs), remplacez ou supprimez la règle par défaut cifs.spnego request-key. Si vous n'avez pas besoin de conteneurs sans privilèges root ou de la fonctionnalité « unshare » sans privilèges, désactivez plutôt les espaces de noms utilisateur sans privilèges. Vous trouverez ci-dessous les commandes à utiliser et les compromis à prendre en compte.

La version longue

Asim Manizada a révélé l'existence de CIFSwitch sur la liste de diffusion oss-security le 28 mai 2026, jour où l'embargo convenu avec les distributions Linux a pris fin. Le rapport initial avait été transmis aux responsables du noyau le 16 mai. Le correctif en amont est accessible au public depuis plus d'une semaine et est en attente d'intégration dans la version stable. Les distributions en aval sont encore en train de l'intégrer.

Le problème au niveau du noyau remonte au commit f1d662a de 2007, qui a ajouté le type de clé cifs.spnego sans mécanisme de validation de la description. La faille est restée latente pendant 19 ans car la chaîne d'exploitation pratique dépend de deux ajouts ultérieurs : les espaces de noms d'utilisateurs non privilégiés dans Linux v3.8 (2013) et la logique de changement d'espace de noms dans cifs-utils (en principe, cela concerne la version 6.14 et les versions ultérieures, mais les rétroportages d'autres correctifs CVE ont également introduit des problèmes dans les anciennes versions de cifs-utils). Sans ces trois éléments réunis, la chaîne ne fonctionne pas de bout en bout.

Manizada explique sans détour dans son article que le bug a été découvert grâce à un raisonnement graphique assisté par un modèle de langage de grande envergure (LLM), portant sur les objets du noyau, leurs propriétés de sécurité et les limites où ces objets passent du noyau à l'espace utilisateur. La technique de découverte est intéressante en soi. Pour l'instant, la question la plus urgente est de savoir ce que fait ce bug et comment y remédier.

Comment fonctionne cette faille

Cette faille exploite quatre éléments : une fonctionnalité du noyau Linux appelée « keyrings », un utilitaire de l'espace utilisateur appelé « cifs.upcall », les espaces de noms utilisateur de Linux et le Name Service Switch (NSS). Chacun de ces éléments fait partie de l'infrastructure standard et remplit sa fonction. Le problème réside dans le fait qu'aucune limite de confiance n'a jamais été imposée entre le noyau et l'espace utilisateur, et le reste de la chaîne découle de cette faille.

Étape 1 : les trousseaux de clés du noyau et le type de clé cifs.spnego

Les trousseaux de clés Linux constituent un sous-système du noyau chargé de stocker les éléments d'authentification, tels que les tickets Kerberos et les clés de chiffrement. Lorsque le noyau a besoin d'une clé qu'il ne possède pas, il demande à l'espace utilisateur d'en générer une via un mécanisme d'appel externe. Une règle dans /etc/request-key.d/ stipule : « pour générer une clé de ce type, exécutez cet utilitaire en tant qu'administrateur ». Pour les montages SMB ou CIFS utilisant Kerberos, le type de clé est cifs.spnego et l'utilitaire par défaut est /usr/sbin/cifs.upcall, fourni dans le paquet cifs-utils.

Lorsque le noyau demande une clé cifs.spnego, il génère une chaîne de description contenant des champs d'autorisation : l'ID utilisateur du montage, l'UID des informations d'identification, l'ID du processus et l'espace de noms cible. Cette chaîne est censée provenir du noyau. L'assistant de l'espace utilisateur se fie à ces champs et s'en sert pour déterminer quelles informations d'identification rechercher et dans quel espace de noms agir.

Étape 2 : vérification de l'absence du noyau

L'espace utilisateur peut appeler directement l'appel système request_key() et demander une clé cifs.spnego avec la description de son choix. Avant l'application du correctif, la définition cifs_spnego_key_type du noyau ne comportait pas le hook .vet_description, qui indique au sous-système de gestion des clés « n'accepter que les descriptions provenant d'une source spécifique ». Sans ce hook, n'importe quel processus non privilégié peut demander une clé cifs.spnego avec une description falsifiée, et le keyring lance cifs.upcall en tant que root avec la description fournie par l'attaquant.

Un détail qu’il convient de souligner d’emblée, tiré de l’analyse de Manizada : le noyau n’a pas besoin de renvoyer une clé pour que cifs.upcall se lance. L’assistant s’exécute en premier. Au moment où le noyau rejette la clé comme non valide, l’assistant root a déjà accompli ce que l’attaquant souhaitait. C’est ce qui rend le manque de validation mentionné plus haut si grave.

Étape 3 : changement d'espace de noms au sein de l'assistant racine

cifs.upcall parses the description, finds upcall_target=app and pid=<some-pid>, and calls setns() to switch into the namespaces of the supplied pid. This is a deliberate feature, intended to make cifs.upcall resolve names against the right filesystem and network view when serving containerized mounts. The problem is that the kernel has just been tricked into trusting an attacker’s pid as if it came from a real kernel-side CIFS operation.

Étape 4 : NSS en tant que primitive de chargement de code

Avant de se déconnecter de l'utilisateur root, cifs.upcall effectue une recherche de compte à l'aide de la fonction getpwuid(). Sous Linux, les recherches de compte passent par le Name Service Switch (NSS), un système modulable configuré dans le fichier /etc/nsswitch.conf qui détermine quelles bibliothèques partagées charger pour chaque type de recherche. Maintenant que cifs.upcall se trouve dans l'espace de noms de montage de l'attaquant, le fichier nsswitch.conf qu'il lit est celui de l'attaquant, et le module NSS qu'il charge est un fichier libnss_*.so.2 contrôlé par l'attaquant. Cet objet partagé s'exécute en tant que root à l'intérieur de l'assistant.

Étape 5 : pérennisation via sudo

Le module NSS de la démonstration publique de concept (PoC) crée un fichier dans le répertoire /etc/sudoers.d/ accordant à l'attaquant le droit NOPASSWD: ALL. Une fois le processus d'assistance terminé, l'attaquant quitte l'espace de noms et exécute la commande sudo. Le shell est alors en mode root. Le fichier binaire cifs.upcall présent sur le disque n'est pas modifié ; l'exploitation se produit au sein du processus d'assistance en cours d'exécution et dans l'espace de noms contrôlé par l'attaquant.

La correction est minime. Le correctif en amont ajoute une fonction cifs_spnego_key_vet_description() de quatre lignes qui compare current_cred() à la clé privée spnego_cred du noyau. Si elles ne correspondent pas, la demande de clé est rejetée avec le code d'erreur -EPERM. Seul le chemin de traitement CIFS propre au noyau est autorisé à instancier une clé de ce type. Cela suffit pour interrompre la chaîne à l'étape 2.

Qui est concerné ?

Le chemin d'exécution vulnérable de cifs.spnego remonte à 2007, mais la chaîne d'exploitation publique n'est pratiquement accessible que sur les systèmes prenant en charge les espaces de noms utilisateur non privilégiés de l'époque de Linux v3.8 et remplissant les autres conditions préalables. Le fonctionnement de la chaîne d'exploitation sur un hôte donné dépend de trois conditions en aval : si cifs-utils est installé, si les espaces de noms utilisateur non privilégiés sont activés et si la politique LSM de l'hôte (SELinux ou AppArmor) bloque une étape quelconque de la chaîne.

Prêt à l'emploi (cifs-utils préinstallé, espaces de noms sans privilèges activés, la politique LSM par défaut autorise la chaîne) : AlmaLinux 9.7 Workstation et l'image cloud Azure, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint Cinnamon 21.3 et 22.3, Kali Linux 2021.4 à 2026.1 sans interface graphique, SLES 15 SP7, SLES SAP 15 SP7 et SLES SAP 16.

Ceci a également été confirmé en interne par KernelCare sur CloudLinux 10. CL est livré avec SELinux désactivé via ses profils « tuned » ; par conséquent, la configuration SELinux qui protège RHEL 10, AlmaLinux 10, Rocky Linux 10 et Oracle Linux 10 ne s'applique pas à CloudLinux 10.

Vulnérable si cifs-utils est installé manuellement : Ubuntu 18.04, 20.04, 22.04 et 24.04 (versions Desktop et Server) (la version 24.04 nécessite en outre l'astuce « aa-exec -p trinity », documentée publiquement, pour contourner la politique « userns » d'AppArmor) ; Pop!_OS 22.04 et 24.04 ; Debian 11, 12 et 13 ; CentOS Stream 9 Cinnamon/KDE/MATE/XFCE ; Rocky Linux 9 KDE et Workstation-Lite ; openSUSE Leap 15.6 ; Rocky Linux 8 GenericCloud ; Oracle Linux 8 et 9 KVM ; Amazon Linux 2023 KVM.

Bloqué par la politique par défaut, mais vulnérable en sous-jacent : la plupart des distributions EL10 (RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10) bloquent le pivot de l'espace de noms cifs.upcall sous SELinux en mode « enforcing ». Ubuntu 26.04 bloque la chaîne dans le cadre de sa politique AppArmor userns par défaut. Fedora 40 à 44 et CentOS Stream 10 bloquent également par défaut. Ces hôtes deviennent exploitables si l'opérateur exécute setenforce 0 ou assouplit les sysctls AppArmor userns.

Non exploitable par le grand public (PoC) : Amazon Linux 2, qui intègre cifs-utils 6.2 et dont la version est antérieure à la logique de changement d'espace de noms. CentOS 7 et RHEL 7, qui ont par défaut user.max_user_namespaces = 0. Kali Linux 2019.4 et 2020.4 avec l'ancienne version de cifs-utils 6.9.

La vulnérabilité dépend en fin de compte de trois facteurs : la disponibilité de cifs.upcall, l'autorisation accordée aux utilisateurs non privilégiés et le blocage ou non du pivot de l'espace de noms par la politique LSM. Vérifiez ces éléments à l'aide des commandes présentées dans la section suivante.

Agir dès maintenant

Cette chaîne comporte deux conditions préalables, chacune offrant une solution efficace. Choisissez celle dont les avantages et les inconvénients correspondent le mieux à votre charge de travail.

Recommandé : remplacer la règle par défaut cifs.spnego relative à la clé de requête

Si l'hôte ne monte pas les partages SMB authentifiés par Kerberos (ce qui est le cas de la plupart des serveurs), la règle par défaut cifs.spnego relative à la clé de requête n'est pas utilisée. La remplacer interrompt la chaîne à l'étape 1. Les montages SMB par client utilisant NTLM ou un mot de passe ne dépendent généralement pas de l'appel ascendant Kerberos SPNEGO, mais vérifiez vos options de montage avant de supprimer cette règle.

echo 'create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S' | sudo tee /etc/request-key.d/cifs.spnego.conf

Modifiez le chemin d'accès à keyctl si votre distribution l'a placé ailleurs. Cela correspond à la solution de contournement recommandée par l'auteur et permet d'annuler proprement la demande de clé, plutôt que de la faire échouer via un binaire ne faisant pas partie du trousseau de clés.

Si vous n'utilisez pas du tout SMB, supprimez complètement le fichier :

sudo rm /etc/request-key.d/cifs.spnego.conf

N'appliquez pas cette configuration sur les hôtes qui montent des partages SMB authentifiés par Kerberos. cifs.upcall est précisément l'assistant de ticket SPNEGO dont dépendent ces montages.

Une fois le correctif appliqué, revenez à la configuration initiale en réinstallant cifs-utils (ce qui rétablit la règle par défaut) ou en supprimant votre fichier de remplacement.

Autre solution : désactiver les espaces de noms des utilisateurs sans privilèges

Le PoC doit se connecter à un espace de noms d'utilisateur et de montage privé avant de déclencher l'appel vers le haut. Le blocage des utilisateurs non privilégiés met fin à la chaîne, quel que soit l'état de cifs-utils.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

Remarque concernant la compatibilité : les espaces de noms d'utilisateurs sans privilèges sont requis par les environnements d'exécution de conteneurs sans root (Podman sans root, Docker sans root, Flatpaks basés sur bwrap), plusieurs sandbox d'intégration continue (CI), la fonction unshare(1) sans privilèges et la sandbox de Chromium. Acceptable sur les machines d'hébergement de charges de travail, mais perturbant sur les machines de développement ou d'hébergement de conteneurs.

Autre option : désinstaller cifs-utils si le client SMB n'est pas utilisé

La plupart des parcs de serveurs n'en ont pas besoin. La désinstallation du paquet supprime à la fois cifs.upcall et la règle de clé de requête par défaut.

# Debian / Ubuntu
sudo apt remove cifs-utils

# RHEL / AlmaLinux / Rocky / Oracle / CentOS Stream
sudo dnf remove cifs-utils

Vérifiez si votre serveur est exposé

# Is cifs-utils installed?
command -v cifs.upcall && (rpm -q cifs-utils 2>/dev/null || dpkg -l cifs-utils 2>/dev/null)

# Is the default cifs.spnego request-key rule present?
cat /etc/request-key.d/cifs.spnego.conf 2>/dev/null

# Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Un hôte ne constitue une cible viable que si le service cifs.upcall est installé, qu'une règle de clé de requête cifs.spnego existe et que l'accès des utilisateurs non privilégiés est autorisé.

Correctif sans redémarrage KernelCare

Situation au 29 mai 2026, 14 h 00 UTC : les correctifs sans redémarrage pour EL8 ont été déployés sur le canal principal. Les correctifs pour AlmaLinux 9 ont également été déployés sur le canal principal. Les correctifs sans redémarrage pour les autres variantes d'EL9, EL10, les noyaux Oracle Linux UEK (UEK6 et UEK7), Ubuntu, Debian et Proxmox VE ont été déployés sur le canal de test.

Une fois disponible dans le flux de test, suivez les instructions ci-dessous pour postuler :

kcarectl --update --prefix test

Une fois validé, le correctif est déployé lors de la prochaine exécution planifiée, ou vous pouvez le récupérer à la demande :

kcarectl --update

Vérifiez que le correctif a bien été appliqué. Ce correctif est fourni sans identifiant CVE et peut être identifié grâce à la description fournie par l'éditeur :

kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)

Une fois qu'un numéro CVE a été attribué, la commande `kcarectl –patch-info | grep CVE-2026-` le fera apparaître.

À surveiller au fur et à mesure que la situation évolue

L'attribution d'un identifiant CVE est toujours en attente. Les mises à jour du noyau distribuées par Red Hat, Ubuntu, Debian, SUSE, Oracle et Amazon sont progressivement déployées à mesure que les distributions en aval intègrent le backport stable en attente.

Nous continuerons à mettre à jour cet article au fur et à mesure de la publication des correctifs sans redémarrage et de l'attribution du numéro CVE.

Appliquez les correctifs à tous les noyaux, sans redémarrage

Si vous n'utilisez pas encore KernelCare, c'est le moment idéal pour découvrir comment les correctifs sans redémarrage peuvent protéger vos systèmes Linux critiques sans nécessiter de fenêtres de maintenance d'urgence ni de temps d'arrêt.

Pour en savoir plus sur KernelCare, cliquez ici →

Résumé

Nom de l'article

Une faille du noyau Linux CIFSwitch permet l'accès aux privilèges root en local

Description

CIFSwitch est une faille de sécurité sous Linux permettant l'escalade des privilèges, qui peut conférer des droits root sur les systèmes utilisant cifs-utils, les espaces de noms utilisateur et une gestion vulnérable du protocole SPNEGO CIFS.

Auteur

Chris DeMars

Nom de l'éditeur

de TuxCare

Logo de l'éditeur