A newly discovered local privilege escalation vulnerability dubbed ‘CIFSwitch’ in the Linux kernel could allow attackers to forge CIFS authentication key descriptions, abuse the kernel’s key request mechanism, and gain root privileges.
The issue impacts multiple Linux distributions that ship vulnerable combinations of the kernel CIFS and cifs-utils (versions 6.14 and higher, although some older variants are also affected).
CIFS (Common Internet File System) is a networking protocol that allows access to files, folders, and devices across a local network. Linux uses it to mount, read, and write data from remote systems.
If a CIFS network share uses Kerberos for authentication, the Linux kernel asks a helper program in user space to perform authentication, with the cifs-utils collection of user-space tools serving as the intermediary.
“The kernel requests a cifs.spnego-type key, and the normal keyutils/request-key config runs cifs.upcall as root to fetch or build the Kerberos/SPNEGO material,” explains Asim Viladi Oglu Manizada, a SpaceX security engineer who discovered and named the CIFSwitch privilege escalation vulnerability in Linux.
The researcher says that the problem consists of the Linux kernel’s CIFS subsystem failing to verify that cifs.spnego key requests originate from the kernel’s CIFS client.
As a result, an unprivileged user can create a forged cifs.spnego request and trigger the normal authentication workflow.
A cifs.spnego key request is used by the Linux keyring subsystem to obtain authentication data needed by the CIFS/SMB client when connecting to a network share using Kerberos/SPNEGO authentication.
The flaw allows the root-privileged cifs.upcall helper to trust attacker-controlled fields that it assumes were generated by the kernel.
By abusing these fields to force a namespace switch and then triggering a Name Service Switch (NSS) lookup before privileges are dropped, a local attacker can load a malicious NSS module and achieve root code execution.
Manizada has published an extensive technical report explaining the cause of the issue and how it can be leveraged to achieve root privileges.
Impact, fixes, and the exploit
Manizada says that CIFSwitch was introduced 19 years ago, in 2007. He adds that it is “non-universal” and exploiting it depends on several factors, such as a vulnerable kernel version.
Other prerequisites include a vulnerable cifs-utils version, the availability of user namespaces, and SELinux/AppArmor policies that don’t block the attack.
Some distributions Manizada confirms as vulnerable with their default configurations are:
- Linux Mint 21.3 / 22.3
- CentOS Stream 9
- Rocky Linux 9
- AlmaLinux 9
- Kali Linux 2021.4–2026.1
- SLES 15 SP7
The researcher noted that various Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux, and Amazon Linux versions might also be vulnerable if ‘cifs-utils’ is installed.
However, there are also versions such as Ubuntu 26.04, Fedora 40-44, CentOS Stream 10, Rocky Linux 10, SLES 16, AlmaLinux 10, and openSUSE Leap 16, where the default SELinux/AppArmor settings prevent exploitation of CIFSwitch.
Also, Amazon Linux 2 and Kali Linux 2019.4 and 2020.4 are not affected at all, as their cifs-utils versions lack the namespace-switch functionality.
CIFSwitch has been fixed by a kernel patch that adds validation of cifs.spnego request origins (upstream commit 3da1fdf), but the exact kernel versions that ship that patch vary per distribution.
The researcher recommends that users disable or blacklist the CIFS module if unused, remove the cifs-utils package if unnecessary, and disable unprivileged user namespaces.
Manizada published a proof-of-concept (PoC) exploit for CIFSwitch, which can help organizations validate the effectiveness of the applied patches and mitigations.
CIFSwitch is the latest in a series of privilege-elevation flaws impacting Linux systems that were recently disclosed, including ‘Copy Fail,’ ‘Dirty Frag,’ ‘Fragnesia,’ ‘DirtyDecrypt,’ and ‘PinTheft.’
Automated pentesting tools deliver real value, but they were built to answer one question: can an attacker move through the network? They were not built to test whether your controls block threats, your detection rules fire, or your cloud configs hold.
This guide covers the 6 surfaces you actually need to validate.
