CIFSwitch stands apart from typical privilege escalation vulnerabilities because of how it was discovered. Asim Manizada, a security engineer at SpaceX, didn’t find it by auditing source code the old-fashioned way. He built an AI-powered framework that constructs semantic graphs of kernel objects and their relationships, then had the models walk those graphs looking for mismatches between what a component creates and what a privileged consumer assumes. The result is a multi-step logic chain that reaches root on major distros, including Linux Mint, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux, and SLES 15.
The vulnerability has been in the Linux kernel since 2007. It lives at the intersection of the kernel’s CIFS client and the cifs-utils helper that handles Kerberos authentication for network file shares. When a CIFS mount needs Kerberos credentials, the kernel requests a key of type cifs.spnego and a root-privileged helper called cifs.upcall runs to fetch the authentication material. The problem is that nothing stops an unprivileged user from making the exact same key request with fabricated fields.
“CIFS/SMB is a Windows-style network filesystem protocol. On Linux, the CIFS kernel client handles the actual filesystem parts: mounting the share, talking SMB to the server, doing reads/writes, etc. But, understandably, for Kerberos-auth’d mounts, kernel CIFS doesn’t roll its own auth stack and instead relies on a userspace helper provided by cifs-utils.” continues the report.
“The interaction happens through Linux keyrings. 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. That brings us to – ahem – the key part.”
The fake description can include an attacker-controlled pid and the field upcall_target=app, which tells cifs.upcall to switch into the namespaces of the supplied process before doing anything else. That’s where the second half of the chain kicks in. Before cifs.upcall drops its root privileges, it calls getpwuid() to look up the target account. That lookup goes through NSS, the Name Service Switch, which loads shared libraries named in nsswitch.conf.
“An attacker in userspace can call request_key("cifs.spnego", totally_fake_description, ...) directly.” continues the report. “In the kernel, the pre-patch cifs.spnego key type does not reject the untrusted userspace-created descriptions, treating them as if they came from kernel CIFS.”
The PoC uses this to drop a sudoers.d config file giving the attacker full sudo access, after which root is one command away.
The full chain is: forge a cifs.spnego key request, point the pid field at a process in a namespace you control, let cifs.upcall switch into your namespace while still root, trigger the NSS lookup before the privilege drop, load your malicious NSS module. Five steps, all logic bugs, no memory corruption.
“The interaction happens through Linux keyrings.” continues the report. “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. That brings us to — the key part.”
The fix is a single kernel-side check added to the cifs_spnego_key_type definition: a .vet_description hook that rejects any cifs.spnego request not originating from CIFS’s own spnego_cred. The patch landed in the upstream kernel more than a week before Manizada published his report, and is queued for stable. But distros ship at different paces, and many vulnerable configurations exist right now on systems waiting for packaged updates.
Whether your system is at risk depends on three things landing together: a vulnerable kernel, a vulnerable cifs-utils version (6.14 or higher, though some older versions backported into scope), and either unprivileged user namespaces enabled or SELinux/AppArmor policies that don’t block the attack. Ubuntu 26.04, Fedora 40-44, CentOS Stream 10, and Rocky Linux 10 block exploitation in their default configurations. Everything else on the confirmed list doesn’t. If cifs-utils is installed on Ubuntu 18.04 through 24.04, Debian 11 through 13, openSUSE Leap 15.6, or Oracle Linux 8 or 9, the attack works. A public PoC is on GitHub.
If you don’t use CIFS or Kerberos authentication for network shares — and most desktop systems don’t — removing cifs-utils or blacklisting the CIFS kernel module closes the issue entirely without waiting for a patch. If you do use it, the kernel update is the right fix. Disabling unprivileged user namespaces also blocks the attack but affects other things, so it’s worth testing before deploying.
The other notable detail here is the method. Manizada didn’t find CIFSwitch by reading code. He used a scaffolded AI framework, complete with graph traversal tools, to build a map of privileged kernel consumers, the objects they trust, and where those objects can be tampered with. The agents found the missing .vet_description hook by reasoning through the graph and noticing that cifs.spnego key descriptions were trusted by a root helper but could be authored by anyone. It’s the same class of vulnerability a skilled human auditor would find. It just took an AI a fraction of the time, and came with a working exploit.
Recently, other Linux privilege-elevation vulnerabilities made the headlines, including Copy Fail, Dirty Frag, DirtyDecrypt, Fragnesia, and PinTheft.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, CIFSwitch)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。