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:

cifs-utils installed (affected version):

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

CIFS module loadable:

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

Unprivileged user namespaces enabled:

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

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

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.

LucienLassalle

@Rod-G Hello,

We are indeed aware of this vulnerability on the Kernel. But I still thank you for this message, it shows that the community is attentive to the subject of safety on our products.

I also fixed the PoC, and I managed to reproduce the flaw. I also took the opportunity to start making a fix.

You highlighted it, but this security flaw is mitigated by respecting our best practices as well as the fact that we are a hypervisor which must keep restricted access.

For vulnerabilities like CopyFail, DirtyFrag, Fragnesia, we have just released the fix. The blog post is here: https://xcp-ng.org/blog/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/

This being similar, there is a good chance that we will fix it and give the same severity.

I would also like to anticipate the question of why a fix has not already been included in the security update released today. Our procedure aims for security but also stability, we pass a CI to avoid regressions, as well as a user testing period. With a deadline of less than a day, this would not have been possible.

Just a quick general reminder, but if you find a security flaw and want to report it to us, the best thing to do is to contact our email: security [at] this domain name.

I hope I was able to give you the most complete answer, don't hesitate if anything is missing.
Respectfully,

Rod G

@LucienLassalle — Thanks Lucien, appreciate the detailed reply. Glad we landed on the same result independently, and the CI/testing rationale makes complete sense — stability matters more than rushing a same-day patch.

Good to see June Updates #1 out covering Fragnesia, ptrace_may_dream, and Pintheft, and good to know CIFSwitch will likely be treated the same way. I'll keep checking the blog and the VSA registry.

And noted on security@ for future reports. Thanks for the great work as always.