CVE-2026-97564: smb: client: reject userspace cifs.idmap descriptions
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject userspace cifs.idmap descriptions
cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vetdescription hook, so userspace can create keys of this type through requestkey(2)/addkey(2) and supply those fields without CIFS origin. A requestkey(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context.
Only accept cifs.idmap descriptions while CIFS is using its private rootcred to request the key. idtosid()/sidtoid() already run under overridecreds(rootcred), so the kernel-originated path is unaffected.
This mirrors commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to trigger the vulnerable path?
The attacker needs the ability to run userspace code that can create or request cifs.idmap keys using request_key(2) or add_key(2). They can provide a non-NULL callout to request_key(2), which causes the request-key mechanism to invoke the cifs.idmap helper.
Why can this lead to elevated impact?
The cifs.idmap helper treats fields in the key description, including owner/group SIDs and UID/GID values, as kernel-originating authority-bearing input. Before the fix, user-controlled descriptions could be consumed by a root usermodehelper through /sbin/request-key -> cifs.idmap.
Does the fix disrupt normal CIFS ID mapping requests?
No. The kernel-originated id_to_sid() and sid_to_id() paths already request keys while using CIFS's private root_cred, so they remain accepted.
What configuration condition indicates exposure?
Exposure exists where userspace can create or request cifs.idmap keys and the cifs.idmap request-key helper is available for invocation. The vulnerable behavior is specifically the acceptance of user-created cifs.idmap descriptions.