Hello! On Tue 15-08-23 06:18:43, Andreas Dilger wrote: > On Aug 15, 2023, at 04:04, Georg Ottinger <g.ottinger@xxxxxx> wrote: > > 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. > > It would be useful to also do a quick grep through the rest of the ext2 > code to check for this bug in other places calling ext2_mew_block() and > similar calls. I did actually check when merging the patch and all the other places are storing returned block in ext2_fsblk_t. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
