CIFSwitch CVE-2026-46243: patch the local-root path, then check your CIFS assumptions

CIFSwitch is the nickname for CVE-2026-46243, a Linux local privilege escalation in the CIFS/SPNEGO path.

The practical answer is short: install the fixed kernel from your vendor and reboot into it.

The more useful answer needs a little patience. This is not a remote SMB bug where someone on the network hits your server and immediately becomes root. The attacker needs a way to run code locally first.

But I would not use “local only” as an excuse to ignore it. On shared Linux hosts, CI runners, developer machines, container hosts, lab systems, and appliances that run third-party apps, local code execution is already part of the threat model. If low-privilege local code can turn into root, that is a real problem.

So the question I would ask is not just “is this CVE high severity?”

The better question is:

Can untrusted local code run here, and is the CIFS/SPNEGO upcall path present?

That question keeps the response grounded. No panic, no shrugging.

The moving parts

CIFS is Linux’s client-side implementation for SMB-style file shares. The Linux kernel CIFS documentation is the best reference for that client path, while Microsoft’s MS-CIFS open specification is the protocol reference. If you mount a Windows share, a Samba share, or another SMB/CIFS share from Linux, this is the general neighborhood.

When a CIFS mount uses Kerberos/SPNEGO authentication, the kernel does not do every piece of authentication alone. It asks userspace for help through Linux keyrings and the request-key mechanism.

In the normal path, the kernel CIFS client creates a cifs.spnego key request. A request-key rule can then run cifs.upcall, usually from cifs-utils, as a privileged helper. That helper reads a key description and uses fields inside it to decide which user, credentials, process, and namespace context belong to the request.

That is already a sensitive boundary. A root helper is trusting a description that is supposed to come from the kernel CIFS client.

The bug is that userspace could create cifs.spnego key descriptions too.

NVD’s CVE text calls out fields such as pid, uid, creduid, and upcall_target. The problem is not that those words exist. The problem is that they influence a privileged helper path, and the kernel was not rejecting descriptions created directly by userspace.

That is the heart of CIFSwitch: userspace could feed trusted-looking CIFS/SPNEGO data into a path where cifs.upcall treated it as kernel-originated context.

What the patch changed

The upstream kernel patch is titled:

smb: client: reject userspace cifs.spnego descriptions

The patch adds validation for the cifs.spnego key type in fs/smb/client/cifs_spnego.c. In plain English, the kernel now checks whether the key description is being created through the CIFS SPNEGO credential path. If an ordinary userspace process tries to create that kind of description, the kernel rejects it.

This is the part I like to pay attention to in vulnerability writeups. The fix is not a giant redesign. It is a small validation boundary that should have existed in front of a privileged helper path.

Small patch, sharp edge.

What makes a machine exposed

I would not describe every Linux box as equally exposed. The public material points to a chain, not a single magic condition.

These are the pieces I would check:

The host is running a vulnerable kernel, or a vendor kernel that has not backported the fix.
cifs-utils is installed.
A request-key rule exists for cifs.spnego that can invoke cifs.upcall.
The CIFS client module is loaded, loadable, or built into the kernel.
Unprivileged user and mount namespaces are available to the attacker.
SELinux, AppArmor, seccomp, or another local policy does not block the path.
The attacker already has local code execution.

The last point matters. This is not “remote attacker over SMB becomes root.” It is “local attacker or local workload may become root if the prerequisites line up.”

That local workload can still be interesting. Think about a compromised low-privilege account, an untrusted CI job, a development container, a plugin system, a shared shell server, or a desktop where someone runs random tools from the internet.

If a machine never runs untrusted local code and does not have the CIFS/SPNEGO pieces installed, the urgency is different. If it is a busy shared runner with cifs-utils installed, I would move faster.

The version trap

Do not make this only a version-number exercise.

The researcher notes that namespace-switching behavior is nominally tied to cifs-utils 6.14 and newer, but backports complicate the story. Vendors also backport kernel fixes without changing the version string to something that looks obvious from upstream.

So I would avoid advice like:

kernel older than X means vulnerable
cifs-utils older/newer than Y means safe

That kind of shortcut feels tidy, but it is not how distro security maintenance works.

Use your vendor advisory. Confirm the fixed package version for your distro stream. Then confirm the machine actually rebooted into the fixed kernel.

Checks I would run

Start with the kernel you are actually running:

uname -r

Then check whether the CIFS helper package is present:

dpkg-query -W cifs-utils 2>/dev/null || rpm -q cifs-utils

Check whether the request-key configuration can call cifs.upcall:

grep -R "cifs.upcall" /etc/request-key* /usr/lib*/request-key* 2>/dev/null

Check whether CIFS is currently loaded or available:

lsmod | grep '^cifs'
modinfo cifs 2>/dev/null | head

Check namespace posture. These knobs vary between distros, so treat them as clues:

sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl user.max_user_namespaces 2>/dev/null

Check local policy:

getenforce 2>/dev/null
aa-status 2>/dev/null

None of these commands proves safety alone. They help you answer a more realistic question:

Is the vulnerable path present on this host, and can untrusted local code reach it?

That is the inventory I would want before deciding whether a temporary mitigation is worth the breakage.

What I would patch first

I would prioritize hosts where low-privilege local code is normal:

Shared Linux servers.
CI and build runners.
Container hosts.
Developer workstations used for untrusted projects.
Lab machines with many users.
Appliances that run apps, plugins, or third-party workloads.
Any system where non-admin shell access exists.

If the host also has cifs-utils and a cifs.spnego request-key rule, I would treat it as a near-term patch-and-reboot item.

For a single-user machine with no CIFS client use and no untrusted local code, I would still patch through normal updates. I just would not write the same incident priority on the ticket.

Mitigations if you cannot reboot yet

The clean fix is the vendor-patched kernel plus a reboot. Everything else is about removing a prerequisite while you wait.

If the machine does not mount SMB/CIFS shares as a client, remove cifs-utils:

sudo apt remove cifs-utils
# or
sudo dnf remove cifs-utils

If the machine does not need CIFS client mounts at all, block the cifs module. This can break legitimate mounts, backup jobs, and workflows that use Windows or Samba shares, so do it deliberately:

echo "blacklist cifs" | sudo tee /etc/modprobe.d/disable-cifs.conf

If CIFS client mounts are still needed but Kerberos/SPNEGO CIFS mounts are not, you can neutralize the cifs.spnego request-key handler. This is more targeted, but it can still break Kerberos-authenticated CIFS mounts:

# /etc/request-key.d/cifs.spnego.conf
create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S

If your workloads allow it, disabling unprivileged user namespaces can remove another required condition. Be careful with that one. Browsers, sandboxed desktop apps, containers, package builders, and CI tools may rely on user namespaces.

Keep SELinux or AppArmor enforcing where your distro supports it. Some advisories note that local policy can block known exploitation paths on some defaults. That is good defense in depth. It is not the kernel fix.

Monitoring while you are exposed

Red Hat suggests auditing userspace key creation through add_key and request_key. That can be noisy, but if you cannot patch immediately it gives you something concrete to watch.

sudo auditctl -a always,exit -F arch=b64 -S add_key -S request_key -k keyring_monitor

Then review audit logs for entries tagged keyring_monitor, especially unexpected cifs.spnego activity from ordinary user processes.

I would treat this as triage telemetry, not comfort. Logs can show suspicious behavior. They do not close the vulnerable boundary.

What the evidence says

Here is the source trail I used.

NVD published CVE-2026-46243 on June 1, 2026 and lists kernel.org as the source. When I checked on June 6, 2026, NVD still marked the record as awaiting enrichment, so I leaned more heavily on the kernel patch, oss-security discussion, and vendor advisories for operational details.

NVD shows two CVSS 3.1 assessments:

kernel.org CNA: 7.1 High, local attack vector, low attack complexity, low privileges required, no user interaction.
CISA-ADP: 7.8 High, also local attack vector, low attack complexity, low privileges required, no user interaction.

The oss-security thread records the public disclosure and later CVE assignment. The researcher write-up explains the chain and why the mismatch between kernel-originated data and userspace-created cifs.spnego descriptions matters.

The distro and vendor advisories line up with that reading:

Red Hat rates the issue Important and describes the impact as low-privileged local user to root code execution under the required conditions.
Debian tracks fixed kernel source package versions across multiple streams, which is a good reminder to trust distro-fixed package versions over upstream guessing.
AlmaLinux says patched kernels were released to production repos and mirrors after the CVE assignment.
SUSE rates the issue Important.
TrueNAS marks impact High for affected TrueNAS CE/Enterprise releases because the CIFS module and cifs-utils path are present, while still calling out the local-access requirement.

That is enough to take CIFSwitch seriously. It is not enough to turn it into vague fear.

What I would not say

I would not call this remote code execution. The sources describe local privilege escalation.

I would not say every Linux machine is equally affected. Exposure depends on the kernel, CIFS client availability, cifs-utils, request-key configuration, namespaces, and local policy.

I would not say “we do not use Windows shares, so we are safe” without checking. Unused functionality can still be installed.

I would not treat AppArmor or SELinux as the final fix. They may block known paths on some defaults, but the kernel-side validation bug still needs the kernel patch.

I would not run public exploit code on production machines to test exposure. Use vendor status, package state, configuration checks, and controlled lab work instead.

My practical rule

For CVE-2026-46243, my rule is:

If untrusted local code can run on the host, patch and reboot as soon as the vendor-fixed kernel is available. Until then, remove one required piece of the chain: cifs-utils, the CIFS client module, the cifs.spnego upcall rule, or unprivileged namespaces, whichever breaks the least on that machine.

That is the boring answer, and I mean that as praise. Verify the path. Remove unnecessary exposure. Reboot into the fixed kernel. Keep the claim as precise as the evidence.

Sources

NVD CVE-2026-46243: https://nvd.nist.gov/vuln/detail/CVE-2026-46243
Linux kernel CIFS documentation: https://www.kernel.org/doc/html/latest/admin-guide/cifs/index.html
Linux kernel CIFS usage guide: https://www.kernel.org/doc/html/latest/admin-guide/cifs/usage.html
Microsoft MS-CIFS protocol overview: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/56412e46-786f-4909-a4a1-dfcb98865f91
cifs.upcall man page: https://manpages.debian.org/testing/cifs-utils/cifs.upcall.8.en.html
Debian security tracker: https://security-tracker.debian.org/tracker/CVE-2026-46243
Debian kernel patch view: https://sources.debian.org/patches/linux/7.0.10-1~bpo13%2B1/bugfix/all/smb-client-reject-userspace-cifs.spnego-descriptions.patch/
oss-security disclosure: https://www.openwall.com/lists/oss-security/2026/05/28/2
oss-security CVE assignment follow-up: https://www.openwall.com/lists/oss-security/2026/06/01/6
Researcher write-up: https://heyitsas.im/posts/cifswitch/
Red Hat RHSB-2026-005: https://access.redhat.com/security/vulnerabilities/RHSB-2026-005
AlmaLinux advisory: https://almalinux.org/blog/2026-05-28-cifswitch/
SUSE CVE page: https://www.suse.com/security/cve/CVE-2026-46243.html
TrueNAS impact statement: https://security.truenas.com/scale/impact-statements/cifswitch/