The Hits just keep on coming. This is the fourth Linux kernel privilege escalation in just a couple of weeks, Copy Fail, Dirty Frag and Fragnesia. This exploit does not rely on memory corruption (no buffer overflows) nor on any race conditions but purely on a logic flaw in authorization.
CIFSwitch -
A Linux local privilege escalation (LPE) vulnerability, “CIFSwitch” enables low-privileged users to gain root access by abusing a logic flaw between the Linux kernel CIFS client and the userspace cifs-utils package.
Any unprivileged local user can use it to gain root in a single command.
The vulnerability was found using an AI-assisted multihop reasoning approach that builds and walks semantic graphs of security-relevant objects and flows, enabling the chaining of subtle logic flaws into a practical exploit. The underlying kernel bug traces back to 2007. However, successful exploitation requires several conditions:
A vulnerable kernel, a compatible cifs-utils version (notably 6.14+ or older builds with backported changes), and unprivileged user namespace creation.
Linux Security Module (LSM) policies such as SELinux or AppArmor that do not block the attack path.
Testing shows that many mainstream distributions are exploitable out of the box when cifs-utils is present. In contrast, others are only exploitable after installing cifs-utils or relaxing default LSM policies.
Mitigation
To prevent this hack, uninstall and disable cifs related packages, especially if you do not use them.
Blocking the CIFS module from loading in the kernel
Disable unprivileged user namespaces. Unprivileged user namespaces are required by rootless containers (Podman rootless, rootless Docker, bwrap flatpaks, several CI sandboxes), unprivileged unshare(1), and Chromium’s sandbox. Possibly Firefox also uses it.
This is one more reason for running a lean and mean arch/eos install with removing all the not required packages and services.
No. If the module is not loaded by default or not built into the Linux kernel, then the module can still be loaded and the exploit can be had. insmod and/or modprobe can be used for this.
But for that, for being able to load the module, the local user must already be privileged .
Therefore, any unprivileged local user cannot possibly use insmod or modprobe to load the module to begin with.
In EOS/Arch uninstalling cifs-utils package will lead to impact on smbclient. As smbclient has a hard dependency on cifs-utils package. And without smbclient, samba package will not work. Again a hard dependency between samba package and smbclient package. So tread carefully.
I cannot confirm or refute this statement. Maybe if unprivileged user namespaces are used then maybe it can be done. Or maybe it cannot be done.
Or it is not possible that there exists any scenario in which a unprivileged local user can execute the insmod or modprobe commands or call the relevant c system calls from libraries directly or in a shell script or a program.
The name CIFS comes from the old and obsolete samba protocol SMB1 (Common Internet File System). Linux still uses this name to mount samba shares (e.g. with mount.cifs). In the mount options you specify the newer SMB2 and SMB3 protocols with option vers=2.0 or vers=3.0.
Therefore, samba on Linux does not work without the CIFS module
One point that stuck me. The person who found this did not test it with Arch or any Arch derived distro. Why is that so? Also the same was observed in the earlier 3 LPE vulnerabilities too. Why is Arch being avoided? Is there some thing going on over here?
So the following were tested to be vulnerable out of box
Linux Mint 21.3/22.3 Cinnamon
Rocky Linux 9 Workstation
Kali Linux 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1
Yep and attempting to remove cifs-utils also does not work. It throws an error.
$
$ sudo pacman -Rn cifs-utils
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing cifs-utils breaks dependency 'cifs-utils' required by smbclient
$
$ sudo pacman -Rn smbclient
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing smbclient breaks dependency 'smbclient' required by kio-extras
:: removing smbclient breaks dependency 'smbclient>=4.24.2' required by samba
$
$ sudo pacman -Rn samba
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing samba breaks dependency 'samba' required by kdenetwork-filesharing
$
So for mitigation there are only three ways,
Firstly is to block the cifs modules from being loaded into the kernel.
Second is to disable unprivileged user namespaces (Will impact a lot)
Finally is to ovverride the cifs.spnego Request-Key Rule
The only reason i can think of is maybe because arch is a rolling distro, therefore has no versions? like it can look different everyday, as stuff gets updated constantly. if they want to test, they also want to provide a version it has been tested on. arch has no version, therefore what will they say what version is vulnerable? they could only say time and date maybe but thats it. but you could also argue that depending on what you install with it, can make a difference again as you can build arch almost how you want (bit like gentoo i think, which also isnt listed)
In addition to what @Mellow said there is no standard installation of Arch Linux in same way as for those distros tested. It is highly likely that many install Arch without cifs-utils, if they have no need for samba or the packages that require it.
Naam : cifs-utils
Versie : 7.5-1
Beschrijving : CIFS filesystem user-space tools
Architectuur : x86_64
URL : https://wiki.samba.org/index.php/LinuxCIFS_utils
Licenties : GPL-3.0-or-later
Groepen : Geen
Voorziet : Geen
Is afhankelijk van : keyutils krb5 pam libcap-ng libwbclient talloc
Optionele afhankelijkheden : python: for smb2-quota and smbinfo script [geïnstalleerd]
Vereist door : smbclient
Optioneel voor : Geen
Conflicteert met : Geen
Vervangt : Geen
Geïnstalleerde grootte : 287,67 KiB
Packager : Nathan <ndowens@artixlinux.org>
Creatiedatum : do 12 mrt 2026 09:09:08 CET
Installatiedatum : ma 20 apr 2026 00:20:53 CEST
Installatiereden : Geïnstalleerd als afhankelijkheid voor ander pakket
Installatiescript : Nee
Gevalideerd door : Handtekening
there is no standard installation of Arch Linux in same way as for those distros tested. It is highly likely that many install Arch without 
KDE packages. I installed Xfce without