Patch "ext2: fix datatype of block number in ext2_xattr_set2()" has been added to the 6.1-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    ext2: fix datatype of block number in ext2_xattr_set2()

to the 6.1-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:
     ext2-fix-datatype-of-block-number-in-ext2_xattr_set2.patch
and it can be found in the queue-6.1 subdirectory.

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



commit 5b998924fef0dbc936ba6f408c1be8434b64f899
Author: Georg Ottinger <g.ottinger@xxxxxx>
Date:   Tue Aug 15 12:03:40 2023 +0200

    ext2: fix datatype of block number in ext2_xattr_set2()
    
    [ Upstream commit e88076348425b7d0491c8c98d8732a7df8de7aa3 ]
    
    I run a small server that uses external hard drives for backups. The
    backup software I use uses ext2 filesystems with 4KiB block size and
    the server is running SELinux and therefore relies on xattr. I recently
    upgraded the hard drives from 4TB to 12TB models. I noticed that after
    transferring some TBs I got a filesystem error "Freeing blocks not in
    datazone - block = 18446744071529317386, count = 1" and the backup
    process stopped. Trying to fix the fs with e2fsck resulted in a
    completely corrupted fs. The error probably came from ext2_free_blocks(),
    and because of the large number 18e19 this problem immediately looked
    like some kind of integer overflow. Whereas the 4TB fs was about 1e9
    blocks, the new 12TB is about 3e9 blocks. So, searching the ext2 code,
    I came across the line in fs/ext2/xattr.c:745 where ext2_new_block()
    is called and the resulting block number is stored in the variable block
    as an int datatype. If a block with a block number greater than
    INT32_MAX is returned, this variable overflows and the call to
    sb_getblk() at line fs/ext2/xattr.c:750 fails, then the call to
    ext2_free_blocks() produces the error.
    
    Signed-off-by: Georg Ottinger <g.ottinger@xxxxxx>
    Signed-off-by: Jan Kara <jack@xxxxxxx>
    Message-Id: <20230815100340.22121-1-g.ottinger@xxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c
index 641abfa4b718a..2f89b1073307b 100644
--- a/fs/ext2/xattr.c
+++ b/fs/ext2/xattr.c
@@ -744,10 +744,10 @@ ext2_xattr_set2(struct inode *inode, struct buffer_head *old_bh,
 			/* We need to allocate a new block */
 			ext2_fsblk_t goal = ext2_group_first_block_no(sb,
 						EXT2_I(inode)->i_block_group);
-			int block = ext2_new_block(inode, goal, &error);
+			ext2_fsblk_t block = ext2_new_block(inode, goal, &error);
 			if (error)
 				goto cleanup;
-			ea_idebug(inode, "creating block %d", block);
+			ea_idebug(inode, "creating block %lu", block);
 
 			new_bh = sb_getblk(sb, block);
 			if (unlikely(!new_bh)) {



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux