CIFSwitch (cifs.spnego LPE): Mitigation and Kernel Update on CloudLinux

Researcher Asim Manizada disclosed CIFSwitch, a Linux kernel local privilege escalation in the CIFS / SMB client’s SPNEGO upcall path. The bug has been latent in the kernel since 2007 and the public proof-of-concept (manizada/CIFSwitch) shipped together with the oss-security disclosure on 2026-05-28. On affected hosts, any unprivileged local user can use it to gain root in a single command. No CVE has been allocated at the time of publication.

The flaw is a missing-validation bug. cifs_spnego_key_type (in fs/smb/client/cifs_spnego.c) has no .vet_description hook, so the kernel does not check that a cifs.spnego key request actually originated from the kernel CIFS subsystem. The description string carries authority-bearing fields — pid, uid, creduid, upcall_target — that the root-running cifs.upcall helper trusts as if they came from the kernel. An unprivileged process can forge that description and submit it via request_key(2) / add_key(2). The kernel’s default request-key rule then spawns cifs.upcall as root with the attacker-controlled fields. With upcall_target=app, cifs.upcall setns(2)-es into the namespace named by the attacker-supplied pid and performs a getpwuid() lookup before dropping privileges — loading the attacker’s libnss_*.so.2 from an attacker-controlled mount namespace and executing arbitrary code as root.

The published PoC stages a private user / mount namespace with a forged /etc/nsswitch.conf and NSS module, forges the cifs.spnego description, lets cifs.upcall load the malicious NSS module as root, writes /etc/sudoers.d/<user> granting NOPASSWD: ALL, then runs sudo for an unrestricted root shell.

Details: public PoC · author write-up · oss-security disclosure · upstream fix 3da1fdf4efbc · NVD entry — CVE pending assignment.

Affected CloudLinux versions

Version	Affected	Will be patched via
CloudLinux 7 (CL7)	✅ No¹	—
CloudLinux 7h (CL7h)	⚠️ Yes, if cifs-utils installed²	CloudLinux kernel / KernelCare livepatch
CloudLinux 8 (CL8)	⚠️ Yes, if cifs-utils installed²	CloudLinux kernel / KernelCare livepatch
CloudLinux 8 LTS (CL8 LTS)	⚠️ Yes, if cifs-utils installed²	CloudLinux kernel-lts package / KernelCare livepatch
CloudLinux 9 (CL9)	⚠️ Yes, if cifs-utils installed²	AlmaLinux kernel / KernelCare livepatch
CloudLinux 9 LTS (CL9 LTS)	⚠️ Yes, if cifs-utils installed²	CloudLinux kernel-lts package / KernelCare livepatch
CloudLinux 10 (CL10)	⚠️ Yes, if cifs-utils installed²	AlmaLinux kernel / KernelCare livepatch
CloudLinux for Ubuntu 22.04 LTS	⚠️ Yes, if cifs-utils installed²	Ubuntu kernel update / KernelCare livepatch

¹ user.max_user_namespaces = 0 by default on CL7; the bug code path is present but the namespace step the exploit pivots through is unreachable in stock configuration.
² The attack chain additionally requires unprivileged user namespaces to be permitted (default on CL7h, CL8, CL8 LTS, CL9, CL9 LTS, and CL10). CL9 has been directly confirmed exploitable; CL7h, CL8, CL8 LTS, CL9 LTS and CL10 are exposed under the same conditions.

A KernelCare livepatch that fixes the bug without requiring a reboot will be available on every affected version. See Stream 3 below for current status.

Apply this mitigation now

The chain has two prerequisites; breaking either one is sufficient. Pick the mitigation that fits your fleet.

Option 1 — Disable the default cifs.spnego request-key callout

If the host does not mount CIFS / SMB shares using Kerberos, the request-key rule is unused and overriding it neutralizes the chain:

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

Or, if you do not use SMB Kerberos authentication on this host at all, remove the file entirely:

sudo rm /etc/request-key.d/cifs.spnego.conf

Compatibility: cifs.upcall is the SPNEGO ticket helper that Kerberos-authenticated SMB mounts depend on. Do not apply this mitigation on hosts that mount Kerberos-authenticated SMB shares.

Option 2 — Disable unprivileged user namespaces

The PoC must enter a private namespace before triggering the upcall. Denying unprivileged userns blocks the chain regardless of cifs-utils state.

# EL family (CL7h, CL8, CL9, CL10):
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

# Debian / Ubuntu family (CloudLinux for Ubuntu and standalone Ubuntu hosts):
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cifswitch.conf

Compatibility: Unprivileged user namespaces are required by rootless containers (Podman rootless, rootless Docker, bwrap flatpaks, several CI sandboxes), unprivileged unshare(1), and Chromium’s sandbox. On typical web-hosting workloads this is acceptable. On developer or container hosts, expect rootless tooling to break.

Option 3 — Uninstall cifs-utils where SMB client functionality is not used

Most server fleets do not need it. Removing the package removes cifs.upcall and the default request-key rule together.

# EL family:
sudo yum remove cifs-utils

# Debian / Ubuntu family:
sudo apt-get remove --purge cifs-utils

To revert any of the above mitigations after the livepatch or a patched kernel is installed:

sudo rm /etc/sysctl.d/99-cifswitch.conf  # if Option 2 was used
sudo sysctl --system                      # restore previous sysctl state
# Reinstall cifs-utils via your package manager if Option 3 was used and you now need SMB client.

Update instructions

There are three release streams. Use the one that applies to your CloudLinux version. As patches land, this article will be updated in place — check the timestamps on the callouts in each stream below.

Stream 1 — CloudLinux kernel (CL7h, CL8)

Both will be CloudLinux rebuilds of the upstream fix.

Updating from the CloudLinux beta channel

Once the patched kernel lands in the beta channel, enable it for a single update:

Instructions for updating CL8 from the beta channel — cloudlinux-updates-testing:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -r

Instructions for updating CL7h from the beta channel — cl7h_beta:

yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -r

Updating from the CloudLinux stable channel

Once the kernel reaches the stable channel, a plain update will pull the patched version, no extra repo enablement needed:

yum update 'kernel*'
reboot
uname -r

Stream 2 — AlmaLinux kernel (CL9, CL10)

CloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. The patched kernel is expected to appear first in the AlmaLinux testing repository, with promotion to production repositories shortly after.

Installing from the AlmaLinux testing repository

The almalinux-release-testing package is not in CloudLinux repositories. Install it from a direct URL, update the kernel, then disable the testing repo.

For CL10:

# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# 2. Update the kernel
dnf update 'kernel*'

# 3. Reboot
reboot

# 4. Verify
uname -r

# 5. Disable the testing repo
dnf config-manager --disable almalinux-testing

For CL9 — same flow, replace the URL in step 1:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm

Once the kernel reaches AlmaLinux production repositories

A plain update will pull the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

Stream 3 — KernelCare livepatch (all affected versions)

Once a livepatch is released to the testing feed:

kcarectl --update --prefix test

After deploying from testing, please report results via a support ticket.

Once promoted to main, the patch arrives automatically on the next scheduled run, or on demand:

kcarectl --update

How to verify you are patched

Streams 1 and 2 (kernel update): Once target versions are released, compare uname -r against the target listed in the corresponding stream callout above.

Stream 3 (KernelCare livepatch): Until a CVE is assigned, the patch is identifiable by its upstream description:

kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)

Once a CVE is assigned, kcarectl –patch-info | grep CVE-2026- will surface it.

How to check whether a host is exposed

On any host you are unsure about, run:

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

# Is the default request-key rule in place?
ls -l /etc/request-key.d/cifs.spnego.conf 2>/dev/null

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

You are not exposed if cifs.upcall is not installed, or the request-key rule file does not exist, or user.max_user_namespaces is 0 (EL family) / kernel.unprivileged_userns_clone is 0 (Debian/Ubuntu family). You are exposed if cifs.upcall resolves to a binary, the request-key rule file exists with the default create cifs.spnego … /usr/sbin/cifs.upcall … line, and unprivileged namespaces are permitted.

References