# CIFSwitch: une faille Linux locale peut donner root via CIFS et cifs.upcall > CIFSwitch: point opérationnel sur cette faille Linux locale liée à CIFS, cifs-utils et cifs.upcall, avec conditions d'exposition et mitigations. - URL canonique : [https://forgetaboutit.fr/blog/cifswitch-linux-root-cifs-spnego/](https://forgetaboutit.fr/blog/cifswitch-linux-root-cifs-spnego/) - Publication : 2026-05-30T14:50:00.000Z - Catégorie : Sécurité - Sujets : CIFSwitch, Linux, CIFS, cifs-utils, Élévation de privilèges, Patch management 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](/blog/cve-2026-31431-copy-fail-linux-root/), [DirtyFrag](/blog/dirtyfrag-linux-lpe-mitigation/) ou [Fragnesia](/blog/fragnesia-cve-2026-46300-dirty-frag-linux/): 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: 1. l'attaquant forge une description `cifs.spnego`; 2. `request-key` déclenche `cifs.upcall` comme dans un flux CIFS légitime; 3. `cifs.upcall` traite les champs comme s'ils venaient du noyau; 4. avec `upcall_target=app`, le helper peut basculer dans les namespaces du `pid` fourni; 5. une résolution NSS se produit avant la baisse finale de privilèges; 6. un namespace contrôlé peut contenir une configuration NSS piégée; 7. 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é: ```bash 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`: ```bash 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é: ```bash lsmod | grep '^cifs' || true ``` Vérifier les réglages de namespaces non privilégiés selon la distribution: ```bash 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: ```bash 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: ```bash apt remove cifs-utils ``` ou, selon la distribution: ```bash 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`: ```bash 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: 1. identifier les hôtes Linux avec `cifs-utils` et CIFS disponibles; 2. prioriser les environnements multi-utilisateurs, CI/CD, conteneurs, bastions et postes développeurs; 3. appliquer une mitigation temporaire compatible avec les usages réels; 4. suivre les bulletins de votre distribution; 5. installer le noyau corrigé; 6. redémarrer si nécessaire; 7. vérifier le noyau réellement chargé après maintenance. Commande simple après redémarrage: ```bash 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](/blog/suivi-cve-pourquoi-quotidien/) 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](/infogerance/). - [Découvrir notre infogérance](/infogerance/) - [Nous contacter](/contact/) - [Prendre rendez-vous](https://koalendar.com/e/faboutit) ## Sources - Asim Manizada - CIFSwitch: a non-universal Linux local root vulnerability - oss-sec - CIFSwitch: Linux kernel/cifs-utils local root via forged cifs.spnego upcall - Linux kernel commit 3da1fdf4efbc - smb: client: reject userspace cifs.spnego descriptions - GitHub - PoC CIFSwitch pour validation défensive ## 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.