CVE-2026-64394: ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a WRITEDAC/WRITEOWNER check to SMB2 SETINFO SECURITY
commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE") added a fp->daccess gate to fsctlsetsparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SETINFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2setinfosec() calls setinfosec() with no per-handle access check.
setinfosec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notifychange(), rewrites the POSIX ACL via setposixacl(), and on KSMBDSHAREFLAGACLXATTR shares removes and rewrites the Windows security descriptor via ksmbdvfssetsdxattr(). Every other persistent-mutation arm of the sibling handler smb2setinfofile() checks fp->daccess first (FILEWRITEDATA / FILEDELETE / FILEWRITEEA / FILEWRITEATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate.
A client can therefore open a handle with FILEWRITEATTRIBUTES only (no FILEWRITEDAC / FILEWRITEOWNER) and use SMB2SETINFO with InfoType SMB2OINFOSECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODEWRITE VFS backstop — the missing fp->daccess check is the entire gate.
Setting a security descriptor is the WRITEDAC / WRITEOWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUSACCESSDENIED by smb2setinfo().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ksmbd (Linux kernel ksmbd)to a version that resolves this vulnerability.Patch commit cc57232cae23 - Compensating control
Limit exposure of SMB2 functionality that could trigger the FSCTL_SET_SPARSE / SMB2 SET_INFO SECURITY permission bypass (e.g., restrict SMB access to trusted clients and networks via firewall/ACL/WAF-like controls), until the kernel fix is applied.
Event History
Frequently Asked Questions
What level of access does an attacker need?
An attacker needs network access to the ksmbd SMB service and a handle opened with FILE_WRITE_ATTRIBUTES. The vulnerable path did not require FILE_WRITE_DAC or FILE_WRITE_OWNER on that handle.
What changes could be made through the affected operation?
The operation can rewrite file owner, group, and mode, update the POSIX ACL, and, on shares using KSMBD_SHARE_FLAG_ACL_XATTR, remove and rewrite the Windows security descriptor.
Are shares using Windows security descriptor xattrs affected differently?
Yes. On KSMBD_SHARE_FLAG_ACL_XATTR shares, the affected operation also removes and rewrites the Windows security descriptor in addition to changing other file permission metadata.