This is a note to let you know that I've just added the patch titled vfs: Check the truncate maximum size in inode_newsize_ok() to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vfs-check-the-truncate-maximum-size-in-inode_newsize_ok.patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@xxxxxxxxxxxxxxx> know about it. >From e2ebff9c57fe4eb104ce4768f6ebcccf76bef849 Mon Sep 17 00:00:00 2001 From: David Howells <dhowells@xxxxxxxxxx> Date: Mon, 8 Aug 2022 09:52:35 +0100 Subject: vfs: Check the truncate maximum size in inode_newsize_ok() From: David Howells <dhowells@xxxxxxxxxx> commit e2ebff9c57fe4eb104ce4768f6ebcccf76bef849 upstream. If something manages to set the maximum file size to MAX_OFFSET+1, this can cause the xfs and ext4 filesystems at least to become corrupt. Ordinarily, the kernel protects against userspace trying this by checking the value early in the truncate() and ftruncate() system calls calls - but there are at least two places that this check is bypassed: (1) Cachefiles will round up the EOF of the backing file to DIO block size so as to allow DIO on the final block - but this might push the offset negative. It then calls notify_change(), but this inadvertently bypasses the checking. This can be triggered if someone puts an 8EiB-1 file on a server for someone else to try and access by, say, nfs. (2) ksmbd doesn't check the value it is given in set_end_of_file_info() and then calls vfs_truncate() directly - which also bypasses the check. In both cases, it is potentially possible for a network filesystem to cause a disk filesystem to be corrupted: cachefiles in the client's cache filesystem; ksmbd in the server's filesystem. nfsd is okay as it checks the value, but we can then remove this check too. Fix this by adding a check to inode_newsize_ok(), as called from setattr_prepare(), thereby catching the issue as filesystems set up to perform the truncate with minimal opportunity for bypassing the new check. Fixes: 1f08c925e7a3 ("cachefiles: Implement backing file wrangling") Fixes: f44158485826 ("cifsd: add file operations") Signed-off-by: David Howells <dhowells@xxxxxxxxxx> Reported-by: Jeff Layton <jlayton@xxxxxxxxxx> Tested-by: Jeff Layton <jlayton@xxxxxxxxxx> Reviewed-by: Namjae Jeon <linkinjeon@xxxxxxxxxx> Cc: stable@xxxxxxxxxx Acked-by: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> cc: Steve French <sfrench@xxxxxxxxx> cc: Hyunchul Lee <hyc.lee@xxxxxxxxx> cc: Chuck Lever <chuck.lever@xxxxxxxxxx> cc: Dave Wysochanski <dwysocha@xxxxxxxxxx> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- fs/attr.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/attr.c +++ b/fs/attr.c @@ -134,6 +134,8 @@ EXPORT_SYMBOL(setattr_prepare); */ int inode_newsize_ok(const struct inode *inode, loff_t offset) { + if (offset < 0) + return -EINVAL; if (inode->i_size < offset) { unsigned long limit; Patches currently in stable-queue which might be from dhowells@xxxxxxxxxx are queue-5.10/vfs-check-the-truncate-maximum-size-in-inode_newsize_ok.patch