CIFSwitch turns Linux CIFS SPNEGO upcalls into local root

critical

CVE

Not assigned

CWE

CWE-269, CWE-287, CWE-863

Affected Surface

Linux kernel CIFS client cifs_spnego_key_type before the upstream fix 3da1fdf4efbc, cifs-utils systems with the default cifs.spnego request-key rule, Hosts with unprivileged user and mount namespaces enabled, Linux Mint 21.3/22.3, CentOS Stream 9, Rocky Linux 9, Kali 2021.4-2026.1, AlmaLinux 9.7, and SLES 15 SP7/SAP profiles reported stock-exploitable, Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux, and Amazon Linux profiles reported exploitable when cifs-utils and permissive policy conditions are present

CIFSwitch is a local root chain at the boundary between the Linux kernel CIFS client and the cifs-utils userspace helper cifs.upcall. Asim Manizada disclosed it on oss-security on 2026-05-28 after a linux-distros embargo, with a public validation repository for defenders.

The issue does not require a malicious SMB server. A local unprivileged process can ask Linux keyrings for a forged cifs.spnego key, causing the normal request-key configuration to launch cifs.upcall as root. The helper then trusts attacker-controlled fields that should only have come from kernel CIFS.

Affected components

The affected project boundary spans two packages:

Component	Why it matters
Linux kernel CIFS client	The `cifs.spnego` key type lacked a description-origin check before the upstream fix `3da1fdf4efbc`
`cifs-utils`	The `cifs.upcall` helper parses `pid`, `uid`, `creduid`, and `upcall_target` from the key description and can switch namespaces before dropping privileges
`request-key` configuration	The default `create cifs.spnego * * /usr/sbin/cifs.upcall %k` rule launches the helper as root
User and mount namespaces	The published chain needs attacker-controlled namespaces to supply a fake NSS configuration and library

Stock exploitability depends on distro defaults. The disclosure lists Linux Mint, CentOS Stream 9, Rocky Linux 9, Kali, AlmaLinux 9.7, and SLES profiles as stock-exploitable in tested configurations. It also lists Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux, and Amazon Linux profiles as exploitable when cifs-utils is installed and policy allows the namespace path.

Root cause

Kernel CIFS legitimately creates cifs.spnego key descriptions when it needs Kerberos/SPNEGO material for an SMB mount:

ver=0x2;host=fs.example.internal;ip4=10.0.0.10;sec=krb5;
uid=0x3e8;creduid=0x3e8;user=alice@EXAMPLE.INTERNAL;
pid=0x4f2a;upcall_target=app

Before the kernel fix, the key type did not verify that a description came from kernel CIFS:

struct key_type cifs_spnego_key_type = {
    .name        = "cifs.spnego",
    .instantiate = cifs_spnego_key_instantiate,
    .destroy     = cifs_spnego_key_destroy,
    .describe    = user_describe,
};

The missing field is .vet_description. Without it, unprivileged userspace can ask for the same key type directly:

request_key("cifs.spnego",
            "ver=0x2;host=x;sec=krb5;uid=0x0;creduid=0x0;pid=0x1234;upcall_target=app",
            NULL,
            KEY_SPEC_PROCESS_KEYRING);

The kernel does not need to return a usable key for the attack to work. The dangerous side effect has already happened: request-key starts cifs.upcall as root with the forged description.

Exploit chain

The chain is a privilege boundary confusion:

unprivileged process
  -> creates private user and mount namespaces
  -> installs namespace-local /etc/nsswitch.conf and libnss_*.so.2
  -> calls request_key("cifs.spnego", forged_description)
  -> /sbin/request-key launches cifs.upcall as root
  -> cifs.upcall trusts forged pid and upcall_target=app
  -> cifs.upcall setns() enters attacker-controlled namespaces
  -> cifs.upcall calls getpwuid() before final setuid()/setgid()
  -> NSS loads attacker-controlled libnss_*.so.2 as root
  -> root code writes a sudoers drop-in or otherwise persists

The decisive detail is the order inside cifs.upcall: namespace switch first, account lookup through NSS second, final privilege drop later. That gives a local attacker a way to make a root helper load a library from an attacker-controlled mount namespace.

Fix

The upstream kernel fix rejects userspace-created cifs.spnego descriptions unless the current credentials are kernel CIFS’s private spnego_cred:

static int cifs_spnego_key_vet_description(const char *description)
{
    if (current_cred() != spnego_cred)
        return -EPERM;

    return 0;
}

struct key_type cifs_spnego_key_type = {
    .name = "cifs.spnego",
    .vet_description = cifs_spnego_key_vet_description,
    ...
};

That stops the chain before request-key can launch the privileged helper for an attacker-supplied description. Userspace hardening is still valuable, but the kernel-side origin check breaks the known path.

How to check exposure

On Linux hosts that run untrusted application code, build jobs, developer workloads, or multi-tenant shells, check all three prerequisites:

# Is the helper installed?
command -v cifs.upcall && cifs.upcall -V 2>/dev/null

# Is the default request-key rule present?
test -f /etc/request-key.d/cifs.spnego.conf && sed -n '1,5p' /etc/request-key.d/cifs.spnego.conf

# Are unprivileged namespaces enabled?
sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null

If cifs.upcall is absent, the request-key rule is absent or neutralized, or unprivileged namespaces are disabled, the published chain is broken. If all are present, prioritize a kernel update or one of the mitigations below.

Mitigation

Patch with your distribution’s fixed kernel or livepatch as soon as it is available. Where patching is not immediate, break one prerequisite.

If Kerberos-authenticated SMB mounts are not required, disable the SPNEGO upcall:

sudo sh -c 'echo "create cifs.spnego * * /bin/false" > /etc/request-key.d/cifs.spnego.conf'

If CIFS/SMB client functionality is not used, remove cifs-utils:

sudo apt-get remove --purge cifs-utils
sudo dnf remove cifs-utils

If your workloads can tolerate it, disable unprivileged user namespaces:

# Debian and Ubuntu family
sudo sysctl -w kernel.unprivileged_userns_clone=0

# EL family
sudo sysctl -w user.max_user_namespaces=0

For application-security teams, the risk model is straightforward: any malicious package, compromised build step, web shell, or low-privilege service account on an exposed host can convert local code execution into root. Treat CIFSwitch as a host escape and secrets exposure issue for developer workstations and CI runners, not only as a “local user” bug.