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