On a read-only share, ksmbd refuses writes over SMB, even from a user whose account could write the files in the underlying filesystem. Such a user can still open an existing file for write on the share, but the WRITE requests that follow are refused. If the open carries an SMB2_CREATE_ALLOCATION_SIZE create context, smb2_open() still calls vfs_fallocate() on the file, and the filesystem allows it because of the user's write permission. The user can thereby reserve any amount of disk space through the read-only share, up to filling the filesystem. The file's size and data do not change. Ignore the context on read-only shares. It requests space for a file being created or overwritten, and such a share permits neither. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges --- Notes: Tested with KASAN using fs/smb/server from ksmbd-for-next f4692d0e3b5e. A 64 MiB allocation context on a read-only share no longer reserves space. The open still succeeds and reports the actual allocation. Writable-share allocation and smbtorture results are unchanged. This fix was developed with LLM assistance. fs/smb/server/smb2pdu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index d17fe9f9ffc6..78758817e692 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -5272,7 +5272,8 @@ int smb2_open(struct ksmbd_work *work) if (IS_ERR(az_req)) { rc = PTR_ERR(az_req); goto err_out1; - } else if (az_req) { + } else if (az_req && + test_tree_conn_flag(tcon, KSMBD_TREE_CONN_FLAG_WRITABLE)) { int err; if (le16_to_cpu(az_req->ccontext.DataOffset) + base-commit: f4692d0e3b5e16d32d4ec7b1e0e58d7dbe74aaf4 -- 2.47.3