Patch "vfs: Check the truncate maximum size in inode_newsize_ok()" has been added to the 5.19-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

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.19-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.patch
and it can be found in the queue-5.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit e04fea8cd8ac26f4d38a6c8f8550dc732235ab0c
Author: David Howells <dhowells@xxxxxxxxxx>
Date:   Mon Aug 8 09:52:35 2022 +0100

    vfs: Check the truncate maximum size in inode_newsize_ok()
    
    [ Upstream commit e2ebff9c57fe4eb104ce4768f6ebcccf76bef849 ]
    
    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: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/attr.c b/fs/attr.c
index dbe996b0dedf..f581c4d00897 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -184,6 +184,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;