A newly disclosed Linux local privilege escalation vulnerability, CIFSwitch, allows an unprivileged local user to gain root access on certain systems via the Linux kernel’s CIFS client and the cifs-utils userspace helper. CIFS, also known as SMB, is a network file-sharing protocol commonly used to access Windows file shares from Linux and other platforms.
Security researcher Asim Manizada disclosed the issue, describing it as a non-universal Linux local root vulnerability since exploitability depends on specific distribution configurations. A public proof-of-concept exploit is available, increasing the urgency for patching and mitigation on affected systems.
CIFSwitch exists at the interface between the kernel CIFS client and cifs.upcall, the cifs-utils helper for Kerberos-authenticated CIFS/SMB mounts. While CIFS is commonly associated with Windows file shares, Linux systems can also mount SMB shares using the kernel CIFS client.
The vulnerability arises from how CIFS uses Linux keyrings. Normally, the kernel requests a cifs.spnego key, and the system’s request-key configuration launches cifs.upcall as root to handle Kerberos/SPNEGO authentication.
According to the disclosure, the vulnerability allows an unprivileged userspace process to request a forged cifs.spnego key description. The kernel failed to properly reject descriptions not originating from kernel CIFS, and the default request-key rule could still launch cifs.upcall as root.
The userspace helper then parsed attacker-controlled fields, including pid, uid, creduid, and upcall_target, as if they were generated by the kernel. By setting upcall_target=app, the helper could switch into a namespace controlled by the attacker.
The attack is particularly dangerous because account lookup through NSS can occur before the final privilege drop. In this state, a namespace-local NSS configuration and module can be loaded by the root helper, enabling attacker-controlled code to run with root privileges.
The public proof-of-concept repository explains that the exploit builds helper code, including a fake NSS library and a trigger that causes cifs.upcall to enter the private namespace and load the controlled NSS module. The author states the PoC is intended for defenders, maintainers, and authorized security teams to validate exposure, patches, and mitigations.
The kernel-side fix is public and queued for stable release. It rejects userspace-created cifs.spnego descriptions by validating that only CIFS using its private spnego_cred credentials can create them. CVE assignment was still pending at the time of publication.
The good news is that CIFSwitch does not affect every Linux system by default. The researcher lists several required conditions: a vulnerable kernel, an affected cifs-utils version, the default cifs.spnego request-key rule, enabled unprivileged user and mount namespaces, and SELinux or AppArmor policies that do not block the attack chain.
The tested stock-exploitable systems listed in the disclosure include Linux Mint 21.3 and 22.3, CentOS Stream 9, Rocky Linux 9, Kali Linux 2021.4 through 2026.1 headless, AlmaLinux 9.7 and Azure cloud image, SLES 15 SP7, SLES SAP 15 SP7, and SLES SAP 16 with SELinux permissive.
Other systems are listed as exploitable under the default policy only if cifs-utils is installed manually. That group includes Ubuntu 18.04 LTS, 20.04 LTS, and 22.04 LTS, Debian 11 “Bullseye”, 12 “Bookworm”, and 13 “Trixie”, Pop!_OS 22.04 and 24.04, openSUSE Leap 15.6, Rocky Linux 8 GenericCloud, Oracle Linux 8 and 9 KVM images, and Amazon Linux 2023 with SELinux permissive.
Several newer systems are blocked by stock security policy even when cifs-utils is present. The disclosure lists Fedora 40 through 44, Ubuntu 26.04 LTS, CentOS Stream 10, Rocky Linux 10, AlmaLinux 10.1, Oracle Linux 10, openSUSE Tumbleweed, openSUSE Leap 16.0, and SLES 16 as blocked by default SELinux or AppArmor policy unless those protections are relaxed.
Mitigations include applying the kernel update when available from the distribution, blocking the cifs module if CIFS/SMB mounts are unnecessary, removing cifs-utils where not needed, overriding the default cifs.spnego request-key rule if Kerberos CIFS authentication is not required, and disabling unprivileged user namespaces.
For additional details, see here.

> But I find very strange and crazy how gnu linux distros ‘seams’ weaker, these last months.
What’s *weaker* about finding/patching vulnerabilities?
vulnerabilities are found on all os’s. There have been many nasty ones in the past and there will be more in future and that is why updates are so important. Ai is also being used by more open source projects to try and find issues faster also. I will continue to do like I always have which is simply installing updates. Heck I have seen vulnerabilities in years past take some time to patch but even then that did not mean you where immediate danger.
I am sure than there a some problems with security on many Operating System.
But I find very strange and crazy how gnu linux distros ‘seams’ weaker, these last months.
Since many users are leaving Windows.
There is a time coincidence, exposing all this ‘vulnerabilities’…
I am not a programmer, even if I was programming on a scientific calculator, longtime ago.
But, my little fingers (french expression) tells me some guys are acting to give Gnu/Linux some low punch in the stomach..
My 2 cents…