CVE-2026-97555: smb: client: fix heap overflow in DACL owner/group rewrite
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix heap overflow in DACL owner/group rewrite
When idmodetocifsacl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by daclptr->size. However, replacesidsandcopyaces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SIDMAXSUBAUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smbace)).
If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation.
Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smbacl) plus numaces sizeof(struct smbace), which covers the smbacl header and room for every ACE at maximum SID size. This replaces the previous split logic that used daclptr->size for cifsacl mounts but numaces sizeof(struct smbace) for modefromsid mounts: both paths can trigger the same rewrite and need the same headroom.
KASAN reports this as: BUG: KASAN: slab-out-of-bounds in buildsecdesc+0x1e8a/0x2680 [cifs] Write of size 4 at addr ffff8881a5e25374 by task chown/5298 ... The buggy address is located 0 bytes to the right of allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)
Affected Software
Event History
Frequently Asked Questions
Which SMB client configurations can trigger the overflow?
Both cifsacl mounts and mode_from_sid mounts are affected because both can rewrite an existing DACL's owner or group SIDs. The issue is not limited to the previously separate allocation path for cifsacl mounts.
What conditions are required for the overflow to occur?
An existing DACL must contain relatively short SIDs, and the rewrite must replace them with owner or group SIDs returned by the cifs.idmap upcall that are longer. The replacement SIDs can contain up to 15 sub-authorities, causing rewritten ACEs to exceed an allocation based on the original DACL length.
How can I identify signs that a system has encountered this issue?
KASAN may report a slab-out-of-bounds write in build_sec_desc in the cifs module. The report can occur while constructing a security descriptor during DACL owner or group rewriting.