Sécurité 30 mai 2026 à 16:50

Collaborer avec mon assistant IA :

CIFSwitch: une faille Linux locale peut donner root via CIFS et cifs.upcall

CIFSwitch est une vulnérabilité locale Linux touchant l'interaction entre le client CIFS du noyau, cifs-utils et cifs.upcall. Un PoC public permet de valider l'exposition.

Illustration d'une alerte sécurité Linux autour de CIFSwitch

Dans le cadre de notre veille sécurité, nous signalons CIFSwitch, une vulnérabilité Linux locale publiée par Asim Manizada après expiration de l’embargo linux-distros.

Le sujet est à traiter sérieusement: dans certaines configurations, un utilisateur non privilégié peut obtenir une exécution de code en root en abusant de l’interaction entre le client CIFS/SMB du noyau Linux, le mécanisme request_key, cifs-utils et le helper cifs.upcall.

Au moment de la publication de cet article, le 30 mai 2026, l’attribution CVE est encore annoncée comme en attente par l’auteur. Le correctif noyau est en revanche public: le commit 3da1fdf4efbc ajoute une validation qui empêche les descriptions cifs.spnego créées depuis l’espace utilisateur d’être acceptées comme si elles venaient du client CIFS du noyau.

Pourquoi CIFSwitch mérite une réaction rapide

CIFSwitch n’est pas une vulnérabilité distante: elle ne permet pas, seule, d’entrer sur un serveur depuis Internet.

Mais une faille locale Linux peut devenir critique dès qu’un attaquant dispose déjà d’un point d’appui:

compte utilisateur compromis;
shell obtenu via une application vulnérable;
job CI malveillant;
conteneur trop permissif;
poste développeur ou bastion partagé;
environnement multi-utilisateurs.

C’est la même lecture opérationnelle que pour Copy Fail, DirtyFrag ou Fragnesia: le risque n’est pas forcément l’accès initial, mais la transformation d’un accès limité en contrôle complet de l’hôte.

Ce qui casse dans CIFSwitch

Le chemin normal est légitime. Lorsqu’un montage CIFS/SMB avec Kerberos a besoin de matériel SPNEGO, le noyau demande une clé de type cifs.spnego. La configuration request-key lance alors cifs.upcall, fourni par cifs-utils, afin de préparer les éléments d’authentification nécessaires.

Le problème vient d’une hypothèse de confiance.

Avant le correctif, un processus utilisateur non privilégié pouvait appeler directement request_key("cifs.spnego", ...) avec une description forgée. Le type de clé cifs.spnego ne vérifiait pas correctement que cette description avait bien été produite par le client CIFS du noyau.

Conséquence: la règle request-key pouvait lancer cifs.upcall en root, avec des champs contrôlés par l’attaquant, notamment pid, uid, creduid et upcall_target.

Le chaînage décrit par l’auteur devient alors dangereux:

l’attaquant forge une description cifs.spnego;
request-key déclenche cifs.upcall comme dans un flux CIFS légitime;
cifs.upcall traite les champs comme s’ils venaient du noyau;
avec upcall_target=app, le helper peut basculer dans les namespaces du pid fourni;
une résolution NSS se produit avant la baisse finale de privilèges;
un namespace contrôlé peut contenir une configuration NSS piégée;
du code contrôlé peut être chargé dans le helper root.

Dit plus simplement: CIFSwitch exploite un écart entre qui crée l’information et qui la consomme comme autoritaire.

Conditions d’exposition

L’auteur insiste sur un point important: CIFSwitch est non universelle. Toutes les machines Linux ne sont pas exploitables par défaut.

Les conditions à vérifier sont les suivantes:

noyau vulnérable, sans le correctif smb: client: reject userspace cifs.spnego descriptions;
cifs-utils installé, avec une version et une configuration exposant le chemin cifs.upcall;
règle cifs.spnego par défaut dans request-key;
module CIFS disponible, chargeable ou intégré;
namespaces utilisateur et mount non privilégiés autorisés;
politiques AppArmor, SELinux ou LSM qui ne bloquent pas le chaînage.

Cette combinaison explique pourquoi certaines distributions sont exploitables en configuration standard, tandis que d’autres sont bloquées par leurs politiques de sécurité par défaut ou par l’absence de cifs-utils.

Distributions et profils à qualifier en priorité

La divulgation publique liste plusieurs systèmes testés. La table est volontairement non exhaustive, mais elle donne une bonne idée des priorités.

Parmi les profils signalés comme exploitables en configuration standard, on trouve notamment:

Linux Mint 21.3 et 22.3 Cinnamon;
CentOS Stream 9 GNOME;
Rocky Linux 9 Workstation;
Kali Linux headless de 2021.4 à 2026.1;
AlmaLinux 9.7 Workstation et image Azure cloud;
SLES 15 SP7, SLES SAP 15 SP7 et SLES SAP 16.

D’autres systèmes sont indiqués comme exploitables si cifs-utils est installé, par exemple plusieurs profils Ubuntu, Debian, Pop!_OS, openSUSE Leap, Rocky Linux 8/9, Oracle Linux 8/9 et Amazon Linux 2023.

À l’inverse, certains profils récents sont bloqués par défaut par AppArmor ou SELinux, mais peuvent redevenir exposés si ces politiques sont assouplies. C’est un point important: il ne suffit pas de lire le nom de la distribution. Il faut vérifier la configuration réelle.

Qualification rapide sur un serveur Linux

L’objectif n’est pas de reproduire le PoC en production. L’objectif est de savoir si l’hôte entre dans le périmètre.

Vérifier si cifs-utils est installé:

dpkg -l cifs-utils 2>/dev/null || rpm -q cifs-utils 2>/dev/null

Vérifier la présence de la règle cifs.spnego:

test -f /etc/request-key.d/cifs.spnego.conf && sed -n '1,80p' /etc/request-key.d/cifs.spnego.conf

Vérifier si CIFS est déjà chargé:

lsmod | grep '^cifs' || true

Vérifier les réglages de namespaces non privilégiés selon la distribution:

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces 2>/dev/null || true

Ces commandes ne suffisent pas à elles seules à conclure, mais elles donnent une première lecture utile: présence de cifs-utils, règle request-key, module CIFS, et capacité à créer des namespaces non privilégiés.

Mitigations possibles en attendant le patch

La remédiation durable reste l’installation d’un noyau corrigé par votre distribution, puis le redémarrage effectif sur ce noyau.

Si le correctif n’est pas encore disponible ou si la fenêtre de redémarrage doit être planifiée, plusieurs mesures compensatoires sont citées dans la divulgation.

Bloquer CIFS si vous ne l’utilisez pas

Si CIFS/SMB n’est pas nécessaire sur l’hôte, vous pouvez empêcher le chargement du module, sous réserve qu’il ne soit pas intégré directement au noyau:

printf 'install cifs /bin/false\n' > /etc/modprobe.d/disable-cifs.conf

Cette mesure doit être validée avant déploiement large: elle peut casser des montages SMB légitimes.

Retirer cifs-utils si le paquet est inutile

Sur des serveurs qui n’utilisent pas de montages CIFS, retirer cifs-utils peut réduire l’exposition:

apt remove cifs-utils

ou, selon la distribution:

dnf remove cifs-utils

Avant suppression, vérifiez les dépendances et les usages réels: montages dans /etc/fstab, scripts d’exploitation, jobs de sauvegarde, partages SMB métiers.

Neutraliser la règle cifs.spnego si Kerberos CIFS n’est pas utilisé

Si vous utilisez CIFS mais pas l’authentification Kerberos/SPNEGO, la divulgation propose de remplacer la règle cifs.spnego par une négation via keyctl:

cat > /etc/request-key.d/cifs.spnego.conf <<'EOF'
create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S
EOF

Là encore, ce n’est pas une commande à pousser aveuglément. Si vous avez des montages CIFS Kerberos, cette mitigation peut casser l’authentification attendue.

Désactiver les namespaces non privilégiés

La désactivation des user namespaces non privilégiés peut aussi réduire l’exposition, mais elle peut impacter des workloads modernes: conteneurs rootless, sandboxes, navigateurs, outils développeurs, CI.

La décision doit donc être prise selon le profil de l’hôte. Sur un runner CI ou une machine développeur, l’effet de bord peut être significatif. Sur un serveur applicatif classique, la mesure peut être plus acceptable si aucun service ne dépend de ce mécanisme.

Patcher reste la vraie réponse

Le correctif noyau ajoute une validation côté cifs.spnego: seules les descriptions produites dans le contexte attendu par CIFS doivent être acceptées. Autrement dit, l’espace utilisateur ne doit plus pouvoir fabriquer une description qui sera traitée comme une vérité venant du noyau.

La trajectoire saine est donc:

identifier les hôtes Linux avec cifs-utils et CIFS disponibles;
prioriser les environnements multi-utilisateurs, CI/CD, conteneurs, bastions et postes développeurs;
appliquer une mitigation temporaire compatible avec les usages réels;
suivre les bulletins de votre distribution;
installer le noyau corrigé;
redémarrer si nécessaire;
vérifier le noyau réellement chargé après maintenance.

Commande simple après redémarrage:

uname -a

Sur Linux, c’est un piège classique: le paquet noyau peut être installé sans que la machine ait encore redémarré dessus.

Notre lecture opérationnelle

CIFSwitch illustre un type de vulnérabilité que les équipes d’exploitation doivent traiter avec méthode: elle n’est pas universelle, mais elle est suffisamment sérieuse pour justifier une qualification rapide.

Le bon réflexe n’est ni la panique, ni l’attente passive.

Il faut croiser:

version de noyau réellement chargée;
distribution et politique de backport;
présence de cifs-utils;
usage réel de CIFS et de Kerberos;
réglages AppArmor, SELinux et namespaces;
exposition locale possible;
criticité de l’hôte.

C’est exactement le rôle d’une veille CVE quotidienne bien intégrée à l’exploitation: transformer une alerte technique en décision concrète, adaptée au parc réel.

Chez Forget About IT, ce type d’alerte entre dans le maintien en condition de sécurité: qualification, priorisation, mitigation, patch, redémarrage contrôlé et vérification post-intervention.

Conclusion

CIFSwitch est une faille Linux locale sérieuse, surtout pour les environnements où un utilisateur non privilégié ou un processus compromis peut déjà exécuter du code.

Le bon réflexe:

vérifier la présence de cifs-utils et de la règle cifs.spnego;
qualifier l’usage réel de CIFS/SMB et Kerberos;
appliquer une mitigation si le patch doit attendre;
suivre les correctifs de votre distribution;
redémarrer sur un noyau corrigé et vérifier le résultat.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la remédiation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre infogérance.

Sources

FAQ: CIFSwitch et Linux local root

Qu’est-ce que CIFSwitch ?

CIFSwitch est une vulnérabilité locale Linux qui combine le client CIFS du noyau, cifs-utils et cifs.upcall. Dans certaines configurations, un utilisateur non privilégié peut déclencher un helper root avec des champs contrôlés.

CIFSwitch a-t-elle une CVE ?

Au 30 mai 2026, l’auteur de la divulgation indique que l’attribution CVE est encore en attente.

L’attaque est-elle distante ?

Non. CIFSwitch est une élévation de privilèges locale: l’attaquant doit déjà pouvoir exécuter du code comme utilisateur non privilégié sur l’hôte.

Quels systèmes sont concernés ?

Les systèmes à qualifier en priorité sont ceux avec un noyau vulnérable, cifs-utils installé, la règle cifs.spnego par défaut, CIFS disponible et les namespaces utilisateur/mount non privilégiés autorisés.

Quelle mitigation appliquer si le patch n’est pas encore disponible ?

Selon les usages, il est possible de bloquer le module CIFS, retirer cifs-utils, neutraliser la règle cifs.spnego si Kerberos CIFS n’est pas utilisé, ou désactiver les namespaces non privilégiés.