cifs-utils LPE (CVE-2026-46243) / 8.3 dom0 vulnerability inquiry

[Rod G]

Hi all,

Flagging CIFSwitch (CVE-2026-46243, assigned June 1) for this community, since it touches dom0 directly. It's the fourth Linux LPE in the recent run after CopyFail, Dirty Frag, and Fragnesia. It spans the kernel's CIFS/SMB client and the cifs-utils userspace helper: an unprivileged local user forges a cifs.spnego key request, the kernel launches cifs.upcall as root, and the helper trusts attacker-controlled fields, switches into the attacker's namespace, and loads a malicious NSS library before dropping privileges — landing a root shell. Latent since 2007, public PoC available.

It's explicitly "non-universal" — the researcher (Asim Manizada) lists five conditions that must all hold. I went through them on a stock 8.3 host, and all five are met:

1. cifs-utils installed (affected version):

[root@xcpng ~]# rpm -q cifs-utils
cifs-utils-7.1-2.1.x86_64

2. CIFS module loadable:

[root@xcpng ~]# modinfo cifs | head -1
filename:  /lib/modules/4.19.0+1/kernel/fs/cifs/cifs.ko

3. Unprivileged user namespaces enabled:

[root@xcpng ~]# sysctl user.max_user_namespaces
user.max_user_namespaces = 9896

4. Default cifs.spnego request-key rule present (the trigger):

[root@xcpng ~]# cat /etc/request-key.d/cifs.spnego.conf
create  cifs.spnego    * * /usr/sbin/cifs.upcall %k

5. No LSM in the way — SELinux disabled by default on dom0:

[root@xcpng ~]# getenforce
Disabled

On several newer EL distros a default-enforcing SELinux policy blocks the chain even with cifs-utils present. dom0 ships with SELinux disabled, so that backstop isn't there for us.
The open question — and the reason I'm posting: all five userspace/config preconditions are met, but that doesn't by itself prove the kernel is exploitable. The deciding factor is whether the upstream fix (commit 3da1fdf, "smb: client: reject userspace cifs.spnego descriptions") has been backported into the current dom0 kernel (4.19.19-8.0.46.2.xcpng8.3). The most recent kernel update (May 2026 Updates #3, May 21) predates the CIFSwitch disclosure on May 28, so I'd assume it hasn't landed yet — but I can't confirm that from the changelog alone.

So, two things:

Has anyone at VATES already tested dom0 against this? A quick yes/no on whether a fully-patched 8.3 host is exploitable would settle it for the whole community, and would tell us whether a kernel update is in the pipeline.
If not, I'll take a crack at it. If I get time today I'll try to stand up the PoC (github.com/manizada/CIFSwitch) against a fully-patched, throwaway 8.3 test host — never anything production — and report back what I find. If someone's already done this, say the word and I won't duplicate the effort.

Context / mitigating factor: this is a local privesc, and a properly locked-down dom0 shouldn't have untrusted shell users to begin with — dom0 is meant to be a black box. So not drop-everything urgent. But it's unnecessary attack surface in the most privileged domain on the host, and a clean pivot after any partial compromise. Cheap to close.

Check your own dom0 (full five-condition sweep):

bashrpm -q cifs-utils
modinfo cifs 2>/dev/null | head -1
sysctl user.max_user_namespaces
cat /etc/request-key.d/cifs.spnego.conf
getenforce

Interim mitigation if you don't mount CIFS/SMB in dom0 (almost certainly the case — SRs use NFS/iSCSI/local):

yum remove cifs-utils

No reboot, no toolstack restart. Or blacklist the module:

echo "blacklist cifs" > /etc/modprobe.d/blacklist-cifs.conf

If you genuinely use CIFS in dom0, override the request-key rule to negate unsolicited requests instead.

Cheers

[Rod G]

Just a quick update for anyone following this thread—I decided to test this out on my end to verify the impact.

After installing gcc in Dom0 and making a few necessary tweaks to the PoC code, I was able to successfully compile and run it. I managed to gain root access starting from a standard, unprivileged account. Based on this, I can confirm that a fully patched XCP-ng 8.3 system is indeed vulnerable to this attack.

However, I want to strongly emphasize a key point about the threat model here so we keep the risk in perspective: this is strictly a Local Privilege Escalation (LPE) vulnerability. An attacker cannot just trigger this remotely. To exploit this, someone absolutely must already have a provisioned account with access to your Dom0. If you are following best practices and strictly controlling who (and what) has shell access to Dom0, your immediate, real-world risk is significantly mitigated.

Hopefully, this helps clarify the exposure for everyone while we wait for an official patch upstream.