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 <[email protected]> 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 request_key("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
>   upcall_target fields as if they came from kernel CIFS.
> 
>   For upcall_target=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

Reply via email to