Mitigating CIFSwitch on Rocky Linux 8, 9, 10, and LTS Variants

cve security kernel cifs rocky linux lts mitigation troubleshooting

Arian Cabrera
Customer Support Engineer

May 28, 2026

Introduction

CIFSwitch is a local privilege escalation (LPE) vulnerability that spans the Linux kernel's CIFS client and the cifs-utils userspace helper. A local unprivileged user can forge a cifs.spnego key request that causes the kernel to launch cifs.upcall as root. The userspace helper then trusts attacker-controlled fields in the key description, switches into the attacker's namespaces, and performs NSS lookups before dropping privileges. That lets the attacker load a malicious NSS library as root and gain a root shell.

The vulnerability was disclosed publicly on 2026-05-27 by Asim Manizada, with the oss-security mailing list announcement following shortly after. A CVE identifier had not been assigned at the time of disclosure. The kernel-side fix is upstream commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions") and is queued for stable.

This article covers Rocky Linux 8, 9, and 10 systems, including CIQ LTS, FIPS, and RLC Pro variants. It describes which systems are exposed, how to install the patched kernel, and which mitigations to apply in the interim.

Problem

The kernel's cifs_spnego_key_type did not validate that incoming cifs.spnego key descriptions originated from kernel code. Any unprivileged process can call request_key("cifs.spnego", attacker_description, ...), which triggers the default /etc/request-key.d/cifs.spnego.conf rule that launches /usr/sbin/cifs.upcall as root.

cifs.upcall parses the description fields (pid, uid, creduid, upcall_target) as if they came from the kernel. When upcall_target=app, the helper enters the namespaces of the process named by the attacker-controlled pid and performs NSS account lookups before dropping privileges. The attacker controls /etc/nsswitch.conf and the libraries under /lib*/libnss_*.so.2 in that namespace, so the helper loads and executes attacker-supplied code as root.

The kernel-side fix (commit 3da1fdf4efbc) adds a .vet_description hook that rejects any cifs.spnego request whose credentials do not match the kernel's SPNEGO credentials. Once that fix is in place, the upcall is never invoked with attacker-controlled data and the vulnerability is closed. A patched kernel is sufficient on its own.

The vulnerable code path has existed since the CIFS SPNEGO key type was introduced in 2007. Treat the following systems as affected unless they are running a patched kernel or have one of the mitigations in place:

Rocky Linux 8, 9, and 10 community releases
Rocky Linux 8 and 9 LTS variants
RLC Pro FIPS variants
RLC Pro variants based on Rocky Linux 8, 9, or 10, including RLC Pro Hardened

Exploitation requires:

Local code execution as an unprivileged user
cifs-utils installed with the default cifs.spnego request-key rule
The cifs kernel module loadable (built-in or modprobe-able) on the running kernel
Unprivileged user namespace creation enabled

Some AppArmor and SELinux policies restrict exploitation, but the default policies on Rocky Linux do not block the exploit chain end-to-end. Treat any system with local shell users, shared application accounts, CI runners, or workloads that allow an attacker to run code as exposed until you apply the mitigation or install a patched kernel.

Status

Patched kernels are available for CIQ variants as of 2026-05-27. See the Patched Kernels table below for exact versions. The kernel-side fix is upstream commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions") and is sufficient on its own; no userspace package update is required to close the vulnerability.
Recommended action: install the patched kernel via dnf update kernel* and reboot. See the Installing the Update section below. If you cannot reboot immediately, apply one of the mitigations in the Mitigation section to reduce exposure until the update can be applied.
CIQ Bridge customers receive a patched kernel as part of this rollout (see the Patched Kernels table). Apply the mitigation in the interim if you cannot update immediately.
Rocky Linux community releases (8.10, 9.7, 10.1) will receive patched kernels from RESF; this article will be updated as those builds ship.
Open a support case if you need help confirming exposure, validating CIFS impact for your workload, or tracking patch availability for a specific CIQ variant.

Patched Kernels

Variant	Patched Kernel Version	Repository	Released
RLC Pro LTS 8.6	`kernel-4.18.0-372.32.1+28.1.el8_6_ciq`	`lts-8.6`	2026-05-27
RLC Pro LTS 8.10	`kernel-4.18.0-553.123.1+6.1.el8_10_ciq`	`lts-8.10`	2026-05-29
RLC Pro LTS 9.2	`kernel-5.14.0-284.30.1+31.1.el9_2_ciq`	`lts-9.2`	2026-05-27
RLC Pro LTS 9.4	`kernel-5.14.0-427.42.1+23.1.el9_4_ciq`	`lts-9.4`	2026-05-27
RLC Pro LTS 9.6	`kernel-5.14.0-570.60.1+12.1.el9_6_ciq`	`lts-9.6`	2026-05-27
RLC Pro FIPS 8.6	`kernel-4.18.0-553.123.1+6.1.el8_6.ciqfips`	`fips-8.6-compliant`	2026-05-29
RLC Pro FIPS 8.10	`kernel-4.18.0-553.123.1+6.1.el8_10_ciq`	`fips-8.10-compliant`	2026-05-29
RLC Pro FIPS 9.2	`kernel-5.14.0-284.30.1+31.1.el9_2_ciq`	`fips-9.2-compliant`	2026-05-29
RLC Pro FIPS 9.6	`kernel-5.14.0-570.60.1+12.1.el9_6_ciq`	`fips-9.6-compliant`	2026-05-29
RLC Pro 8	`kernel-4.18.0-553.123.1+6.1.el8_10_ciq`	`rlc-pro-8`	2026-05-29
RLC Pro 9	`kernel-5.14.0-611.54.1+6.1.el9_7_ciq`	`rlc-pro-9`	2026-05-29
CIQ SIG/Cloud Next 8	`kernel-4.18.0-553.123.1+6.1.el8_10_ciq`	`ciq-sigcloud-next-8`	2026-05-29
CIQ SIG/Cloud Next 9	`kernel-5.14.0-611.54.1+6.1.el9_7_ciq`	`ciq-sigcloud-next-9`	2026-05-29
CIQ SIG/Cloud Next 10	`kernel-6.12.0-124.55.1+5.1.el10_1_ciq`	`ciq-scn-10`	2026-05-29
CIQ Linux Kernel LT 6.12	`kernel-clk6.12-6.12.89-2.1.el9_clk`	`rlc-9-clk-6.12`	2026-05-29
CIQ Linux Kernel LT 6.18	`kernel-clk6.18-6.18.33-2.1.el9_clk`	`rlc-9-clk-6.18`	2026-05-29
CIQ Bridge for CentOS 7.9	`kernel-3.10.0-1160.119.1.ciqcbr.12.1`	`ciq-bridge`	2026-05-27

Confirm what is running on a given system with:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place and the mitigation can be reverted. See Resolution.

Installing the Update

RLC Pro LTS Variants

For RLC Pro LTS 8.6, 9.2, 9.4, and 9.6, the patched kernel is available directly from the long-term support repository. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

CIQ Bridge for CentOS 7.9

For CIQ Bridge customers running CentOS 7.9, the patched kernel is available from the CIQ Bridge repository:

sudo yum update kernel*
sudo reboot

RLC Pro, FIPS, SIG/Cloud Next, and CIQ Linux Kernel LT Variants

Patched kernels for RLC Pro 8, RLC Pro 9, RLC Pro FIPS, CIQ SIG/Cloud Next 8/9/10, and CIQ Linux Kernel LT 6.12/6.18 are now available from their respective depot repositories. No additional repository configuration is required beyond what your variant already uses:

sudo dnf update kernel*
sudo reboot

Community Edition (RESF)

For Rocky Linux 8.10, 9.7, and 10.1 community editions from RESF, the patched kernel will be available from the standard BaseOS repository once RESF builds ship. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

Mitigation

Four mitigation options are available. The request-key override (Option A) is the least disruptive and is recommended for hosts that mount CIFS shares. If CIFS is not used on the host, blocking the cifs module (Option B) or uninstalling cifs-utils (Option C) is simpler. Option D (disabling unprivileged user namespaces) is a broader system control that also covers CIFSwitch.

Option A (recommended): Override the cifs.spnego request-key rule

The default request-key rule at /etc/request-key.d/cifs.spnego.conf is what causes the kernel to launch cifs.upcall as root on any user-supplied cifs.spnego request. Replacing the rule so that unsolicited requests are negated removes the privileged-helper entry point without unloading any kernel modules. Kernel-initiated CIFS authentication continues to work once a patched kernel is installed, because the kernel patch teaches the kernel to vet descriptions before invoking the helper.

Warning: While this override is in place, CIFS Kerberos/SPNEGO authentication for new mounts will fail because cifs.upcall is not invoked. Already-mounted CIFS shares continue to operate until their credentials expire. If the host relies on Kerberos-authenticated CIFS mounts, plan accordingly or use Option C and uninstall cifs-utils outright on hosts that do not need it.

Back up the existing rule and install the override:

sudo cp /etc/request-key.d/cifs.spnego.conf /etc/request-key.d/cifs.spnego.conf.bak
sudo sh -c 'printf "create cifs.spnego * * /usr/bin/keyctl negate %%k 30 %%S\n" > /etc/request-key.d/cifs.spnego.conf'

The negate action returns ENOKEY to the requesting process for 30 seconds and never invokes cifs.upcall. Confirm the override is in place:

cat /etc/request-key.d/cifs.spnego.conf

You should see the single create cifs.spnego ... keyctl negate line.

To revert once the patched kernel is installed:

sudo mv /etc/request-key.d/cifs.spnego.conf.bak /etc/request-key.d/cifs.spnego.conf

Option B: Block the cifs kernel module

If the host does not mount CIFS/SMB shares, the simplest mitigation is to prevent the cifs module from loading. This removes the kernel-side entry point entirely.

Warning: Blocking the cifs module breaks mount -t cifs and any service that relies on SMB/CIFS shares. Validate before applying fleet-wide.

Install the modprobe override:

sudo sh -c 'printf "install cifs /bin/false\n" > /etc/modprobe.d/cifswitch.conf'

If cifs is already loaded, unload it after stopping any consumers:

sudo umount -a -t cifs
sudo rmmod cifs

If rmmod reports the module is in use, a CIFS share is still mounted. Identify it with mount | grep cifs and unmount before retrying. If a reboot is acceptable, rebooting also clears the loaded module and lets the modprobe override take effect cleanly.

To revert once a patched kernel is installed:

sudo rm /etc/modprobe.d/cifswitch.conf
sudo modprobe cifs

Option C: Uninstall cifs-utils

If the host neither mounts CIFS shares nor needs to in the future, uninstalling cifs-utils removes cifs.upcall entirely and is the most decisive mitigation:

sudo dnf remove cifs-utils

This also removes the /etc/request-key.d/cifs.spnego.conf rule, so no request-key override is needed. The cifs kernel module can still be loaded but has no userspace helper to call.

Option D: Disable unprivileged user namespaces (wider blast radius)

The exploit requires unprivileged user namespace creation to set up the attacker-controlled namespace that cifs.upcall enters. Disabling unprivileged user namespaces blocks the exploit, but has a wide blast radius and is generally only appropriate if the workload already does not rely on user namespaces.

Warning: Disabling unprivileged user namespaces breaks rootless container runtimes (rootless Podman, rootless Docker, slirp4netns, pasta), sandboxed browsers such as Chromium and Firefox, and Flatpak applications. If you have already applied this sysctl for Dirty Frag or Fragnesia, it covers CIFSwitch as well; no additional configuration is required.

Apply:

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/cifswitch.conf
sudo sysctl --system

Verify:

sysctl user.max_user_namespaces

Output should be user.max_user_namespaces = 0.

To revert:

sudo rm /etc/sysctl.d/cifswitch.conf
sudo sysctl --system

Verification

After applying the mitigation, confirm it is active.

For Option A (request-key override):

cat /etc/request-key.d/cifs.spnego.conf

The file should contain only the create cifs.spnego ... keyctl negate line. To confirm the kernel honors it, as an unprivileged user trigger a cifs.spnego request and watch for it to be negated rather than upcalled. On a mitigated host, the request returns ENOKEY and cifs.upcall is not spawned.

For Option B (module block):

lsmod | grep '^cifs[[:space:]]'

No output means the cifs module is not currently loaded. Confirm the override is honored on future load attempts:

sudo modprobe -n -v cifs

The command should print install /bin/false. If it resolves to a .ko path, re-check that /etc/modprobe.d/cifswitch.conf is present and readable.

For Option C (uninstall):

rpm -q cifs-utils
which cifs.upcall

The first command should report the package is not installed; the second should produce no output.

For Option D (user namespace sysctl):

sysctl user.max_user_namespaces