CVE-2026-46243

What it actually does

This is a local privilege-escalation flaw in the Linux kernel CIFS/SMB client key-handling path. CIFS uses cifs.spnego keys and the cifs.upcall helper to obtain authentication material for SMB mounts. The vulnerable behavior allowed unprivileged userspace to create cifs.spnego key descriptions through key-management interfaces such as request_key(2) or add_key(2), even though fields in those descriptions, including pid, uid, creduid, and upcall_target, are authority-bearing and should only be trusted when generated by the kernel CIFS client. A local attacker could supply forged cifs.spnego descriptions that cifs.upcall treats as kernel-originated input, potentially causing authentication or credential handling to occur under attacker-influenced identity parameters. The security impact is primarily unauthorized elevation of privileges and exposure or misuse of credentials associated with CIFS/SMB authentication.

Why it matters to the business

Systems that allow local user access and use Linux CIFS/SMB client functionality may be exposed to privilege escalation or credential misuse. Successful exploitation could let a low-privileged local user gain access to sensitive SMB authentication context or perform actions with privileges they should not have, increasing the risk of data theft, lateral movement through file shares, and compromise of systems that rely on network-mounted SMB resources. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it affects a core operating-system component and should be prioritized on multi-user Linux servers, developer workstations, jump hosts, VDI systems, and any Linux hosts mounting SMB shares.

How an attack unfolds

An attacker first needs local code execution as a low-privileged user on a vulnerable Linux system. They then interact with the kernel keyring facility using request_key(2), add_key(2), or tools such as keyctl to create or request a key of type cifs.spnego. Instead of allowing the kernel CIFS client to generate the key description, the attacker supplies a crafted description containing authority-bearing fields such as pid, uid, creduid, or upcall_target. When CIFS authentication handling invokes cifs.upcall, the helper may treat those attacker-controlled fields as trusted kernel-originated data. By shaping those fields, the attacker attempts to influence which credentials are used or how the upcall is processed, resulting in unauthorized access to authentication material or privilege-sensitive SMB operations. The fix changes CIFS behavior so cifs.spnego descriptions are accepted only when the kernel CIFS client is using its private spnego_cred to request the key, rejecting userspace-created descriptions.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the CIFS client change titled "smb: client: reject userspace cifs.spnego descriptions." No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the operating-system or appliance vendor for the affected distribution. Prioritize updating systems that permit local user logins and systems that mount SMB/CIFS shares. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or unloading the CIFS client where not required, removing or limiting cifs-utils/cifs.upcall on systems that do not need SMB mounts, and reviewing mount workflows that depend on Kerberos/SPNEGO authentication. Avoid relying solely on mitigations because the vulnerable logic is in the kernel/client credential path and the robust fix is to apply the corrected kernel.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix, not merely that an updated kernel package is installed. Validate by checking the active kernel version with uname -r and comparing it with the vendor advisory for this issue, then reboot into the fixed kernel if required. On source-based or custom kernels, verify the CIFS client patch that rejects userspace-created cifs.spnego descriptions unless CIFS is using its private spnego_cred is present. Check whether CIFS is in use with lsmod | grep cifs, mount | grep -E 'type cifs|//', and package inventory for cifs-utils. On systems where exposure remains, test that unprivileged users cannot successfully create or influence cifs.spnego upcall descriptions in a way accepted by CIFS authentication handling. Also verify audit or EDR telemetry is capturing add_key/request_key/keyctl activity for future detection.

Typical attack path

1. Obtain local, low-privileged shell or code execution on a Linux host.
2. Confirm the host has CIFS/SMB client support available, such as the cifs kernel module and cifs-utils/cifs.upcall helper.
3. Use key-management interfaces such as add_key(2), request_key(2), or keyctl to create or request a cifs.spnego key from userspace.
4. Craft the cifs.spnego key description with attacker-controlled authority-bearing fields such as pid, uid, creduid, or upcall_target.
5. Trigger CIFS authentication or SMB mount-related activity that causes cifs.upcall processing.
6. Abuse the trusted handling of the forged description to influence credential handling or perform actions with privileges beyond the attacker's account.
7. Use the gained access to read sensitive files, access SMB shares, harvest credentials, or pivot laterally.

How to detect it

Retrospective detection should focus on evidence that an unprivileged user attempted to create or request cifs.spnego keys from userspace and on unusual cifs.upcall activity. Review auditd logs, EDR telemetry, shell history, process creation logs, and Linux authentication/session logs for keyctl, add_key, or request_key activity involving cifs.spnego. If auditd syscall logging is available, search for add_key and request_key syscalls, particularly by non-root users, and correlate them with execution of /usr/sbin/cifs.upcall or SMB mount activity. Examine /proc/keys or captured forensic memory/keyring artifacts for cifs.spnego key descriptions containing authority-bearing fields such as pid=, uid=, creduid=, or upcall_target= that appear to have been created outside normal CIFS mount flows. Review mount logs and systemd journal entries for unexpected CIFS authentication attempts, failed or repeated SPNEGO upcalls, and SMB share access occurring shortly after suspicious key-management operations. Because this is a local kernel/client-side privilege-escalation issue, network indicators may be absent; prioritize host telemetry and user/process correlation.

• cifs.spnego
• keyctl add cifs.spnego
• keyctl request cifs.spnego
• add_key cifs.spnego
• request_key cifs.spnego
• /usr/sbin/cifs.upcall
• cifs.upcall
• upcall_target=
• creduid=
• uid=
• pid=
• type cifs
• mount.cifs

What your security team should do

• Patch affected Linux kernels using vendor-provided updates, prioritizing multi-user systems and hosts that mount SMB/CIFS shares.
• Inventory Linux hosts with CIFS enabled or cifs-utils installed, especially systems using Kerberos/SPNEGO authentication for SMB mounts.
• Restrict local access to trusted users until patching is complete; this vulnerability requires local low-privileged execution.
• Review auditd, EDR, and SIEM coverage for key-management syscall activity, including add_key, request_key, and keyctl usage involving cifs.spnego.
• Hunt for unusual cifs.upcall executions, user-created cifs.spnego keys, and suspicious keyctl commands executed by non-administrative users.
• Disable CIFS support or remove cifs-utils on systems that do not require SMB client functionality.
• For custom kernels, backport the upstream CIFS fix and confirm the running kernel contains it after deployment.
• Treat findings on jump hosts, build systems, VDI, and shared Linux servers as higher priority because local privilege escalation has greater operational impact there.