The vulnerability affects cifs.upcall in cifs-utils. When processing a cifs.spnego key request, cifs.upcall may switch into attacker-controlled namespaces before fully dropping its root privileges. During this transition, the helper performs NSS lookups using getpwuid() while still retaining privileged kernel credentials. An attacker may create a controlled user and mount namespace containing a malicious NSS configuration and NSS module. By triggering a crafted cifs.spnego request through requestkey(), the attacker can cause cifs.upcall to load the malicious NSS module before privileges are fully dropped.
This has been assigned CVE-2026-46243, see https://lore.kernel.org/linux-cve-announce/2026060140-CVE-2026-46243-3d1c@gregkh/
On Thursday, May 28th, 2026 at 12:07 AM, manizada <manizada () pm me> wrote: Hi folks,
Emailing here now that the embargo agreed upon with linux-distros@ has expired.
Flagging a local root vulnerability spanning both CIFS in the kernel and cifs-utils in userspace (originally reported to kernel/cifs maintainers on May 16). The kernel-side (only) fix has now been public for over a week and is queued for stable:
3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions")
Impact: Unprivileged user -> root code exec on any system where: - cifs-utils is installed (with the default cifs.spnego rule) - CIFS kernel module is loadable/compiled-in (typically the case), and - unprivileged user/mount namespaces are enabled.
Some default AppArmor/SELinux profiles block this.
Bug: An unprivileged user can call requestkey("cifs.spnego", ...) with a forged CIFS SPNEGO description. The request-key rule starts cifs.upcall as root. cifs.upcall then trusts attacker-supplied pid, uid, creduid, and upcalltarget fields as if they came from kernel CIFS.
For upcalltarget=app, affected cifs-utils versions switch into the supplied process's namespaces and perform NSS lookup before final privilege drop. A private mount namespace containing attacker-controlled /etc/nsswitch.conf and libnss.so.2 is therefore sufficient for code execution in the root helper.
Affected distros: This a non-exhaustive summary of some tested distros. The full table, including the cases where stock policy blocks exploitation (but relaxing AppArmor/SELinux/etc. enables exploitation), is in the attachment (and in an easier-to-read format in the writeup linked below).
Stock-default exploitable distros (cifs-utils comes preinstalled in the profile + unprivileged namespaces permitted by default + the AA/SELinux policies, if any, do not block the attack):
- Linux Mint Cinnamon 21.3 and 22.3 - CentOS Stream 9 GNOME - Rocky Linux 9 Workstation - Kali Linux headless 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1 - AlmaLinux 9.7 Workstation/Azure cloud image - SLES 15 SP7/SAP 15 SP7/SAP 16
Exploitable if cifs-utils is installed, with no other default config changes: - Ubuntu 18.04/20.04/22.04 Desktop/Server - Pop!OS 22.04 Intel/24.04 Generic - Ubuntu 24.04 Desktop minimal/full and Server - Debian 11/12/13 netinst standard and GNOME/KDE/standard/XFCE - CentOS Stream 9 Cinnamon/KDE/MATE/XFCE - Rocky Linux 9 KDE/Workstation-Lite - openSUSE Leap 15.6 GNOME/KDE - openSUSE Tumbleweed GNOME/KDE - Rocky Linux 8 GenericCloud - Oracle Linux 8/9 KVM - Amazon Linux 2023 KVM
Immediate-term mitigations (aside from backporting the kernel fix): - Blocking the CIFS module from loading (assuming it's not built-in)/uninstalling cifs-utils if not used - Deleting/overriding the default cifs.spnego request-key rule (if Kerberos cifs is not required), e.g., after adjusting for your keyctl path:
cat >/etc/request-key.d/cifs.spnego.conf <<'EOF' create cifs.spnego /usr/sbin/keyctl negate %k 30 %S EOF
- Disabling unprivileged user namespaces
The CVE # assignment is still pending.
Full writeup: https://heyitsas.im/posts/cifswitch
PoC to validate mitigations: https://github.com/manizada/CIFSwitch
Thanks, -Asim Manizada
A flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host's Kerberos credentials cache.