RHSB-2026-005 CIFS Upcall Privilege Escalation - Linux Kernel (CVE-2026-46243) - "CIFSwitch"
Mis à jour
Est-ce que cette infomation vous a été utile ?
Commentaires annulés
Executive Summary
A vulnerability has been identified in the Linux kernel's CIFS (SMB) client subsystem. A low-privileged local user could exploit this flaw to execute arbitrary commands as root.
Red Hat has assessed this issue with a severity of Important and fixes are in progress. This flaw is tracked as CVE-2026-46243. Log in with your Red Hat account, then click the "Follow" button below to be notified of updates.
Note: Environments without Windows file servers or Active Directory typically do not require CIFS functionality. Disabling the cifs kernel module, removing the cifs-utils package, or deactivating the cifs.spnego request-key rule will disrupt the attack chain, as all three must be present for exploitation. Restricting local access to trusted users helps reduce the risk of exploitation.
Affected Products
The following products are affected:
- Red Hat Enterprise Linux 10, 9, 8, 7, 6
Further, any Red Hat product that relies on the Red Hat Enterprise Linux kernel (including RHEL CoreOS) is also potentially impacted. This includes layered products such as Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, and Red Hat Virtualization.
Technical Summary
By forging cifs.spnego key descriptions via request_key(2), an attacker can trigger cifs.upcall (a privileged Kerberos helper) with attacker-controlled parameters. Combined with Linux user namespace and mount namespace manipulation, the attacker can force cifs.upcall to load a malicious NSS shared library, achieving local privilege escalation.
The flaw exists in fs/smb/client/cifs_spnego.c, which registers the cifs.spnego key type without validating that key creation requests originate from the kernel's CIFS subsystem. The key description contains authority-bearing fields (pid, uid, creduid, upcall_target) that cifs.upcall treats as trusted, kernel-originating inputs — but userspace can create keys of this type through request_key(2) or add_key(2), supplying crafted values for these fields.
Mitigation
Overall Guidance
Applying the kernel fix, when available, is the only comprehensive remediation. The mitigation below reduces the attack surface but does not address the root cause.
Disabling the CIFS kernel module
If SMB/CIFS client functionality is not required, disable or blocklist the cifs kernel module.
Warning: This prevents all CIFS/SMB client mounts on the system. Evaluate whether SMB file shares or DFS are used in your environment before applying. If the cifs module is already loaded, it must be unloaded for the blacklist to take effect. Unmount any active CIFS shares first, then unload with modprobe -r cifs. If unmounting is not possible, a reboot is required.
echo "blacklist cifs" > /etc/modprobe.d/disable-cifs.conf
Monitoring for exploitation
If deploying the above mitigation is not feasible, the following monitoring approach can help detect exploitation attempts.
Audit userspace key creation using auditd. The following rule logs all add_key and request_key system calls, which are used during the exploitation of this flaw:
auditctl -a always,exit -F arch=b64 -S add_key -S request_key -k keyring_monitor
Review the audit log for entries tagged with keyring_monitor. Entries showing request_key calls with cifs.spnego key descriptions originating from non-kernel processes may indicate exploitation attempts.
Comments