linux-ext4 - Re: [PATCH v1] ext2: fix datatype of block number in ext2_xattr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230816102049.oxunyinqjclxhsss@quack3>
Date:   Wed, 16 Aug 2023 12:20:49 +0200
From:   Jan Kara <jack@...e.cz>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Georg Ottinger <g.ottinger@....at>, jack@...e.com,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH v1] ext2: fix datatype of block number in
 ext2_xattr_set2()

Hello!

On Tue 15-08-23 06:18:43, Andreas Dilger wrote:
> On Aug 15, 2023, at 04:04, Georg Ottinger <g.ottinger@....at> 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@...e.com>
SUSE Labs, CR