CVE-2026-64398: ksmbd: add a permission check for FSCTL_SET_ZERO_DATA
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a permission check for FSCTLSETZERODATA
FSCTLSETZERODATA in smb2ioctl() destroys file data via ksmbdvfszerodata() -> vfsfallocate(PUNCHHOLE/ZERORANGE) after checking only the share-level KSMBDTREECONNFLAGWRITABLE, with no per-handle access check. A handle opened with only FILEWRITEATTRIBUTES still yields an FMODEWRITE filp (FILEWRITEATTRIBUTES is part of FILEWRITEDESIREACCESSLE, so smb2createopenflags() opens it OWRONLY), so the vfsfallocate FMODEWRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILEWRITEATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILEWRITEDATA right to (6/6; a FILEREADDATA-only handle was correctly denied).
This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE"). Because SETZERODATA writes data (not an attribute), require FILEWRITEDATA.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which deployments are exposed?
Exposure requires ksmbd to serve a writable SMB share. An authenticated SMB client that can open a file with FILE_WRITE_ATTRIBUTES, even without FILE_WRITE_DATA, can trigger the issue.
What does an attacker need to exploit this?
The attacker needs network access to the SMB service and valid authentication with sufficient rights to obtain a FILE_WRITE_ATTRIBUTES-only handle. No user interaction is required, and the reported attack has low complexity.
What is the practical impact of a successful exploit?
The client can use FSCTL_SET_ZERO_DATA to zero file contents despite lacking FILE_WRITE_DATA permission. The issue can destroy file data, affecting integrity and availability.
Are read-only file handles affected?
A FILE_READ_DATA-only handle was reported to be correctly denied. The bypass was reproduced specifically with a FILE_WRITE_ATTRIBUTES-only handle.
Is a fix available?
Yes. The vulnerability is resolved by adding a FILE_WRITE_DATA permission check for FSCTL_SET_ZERO_DATA, and patch references are provided.