linux-ext4 - Aw: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <trinity-bf36bcac-6e5f-4c5c-aed5-f8981803a1b8-1692187013964@msvc-mesg-gmx105>
Date:   Wed, 16 Aug 2023 13:56:54 +0200
From:   Georg Ottinger <g.ottinger@....at>
To:     Jan Kara <jack@...e.cz>
Cc:     Andreas Dilger <adilger@...ger.ca>, jack@...e.com,
        linux-ext4@...r.kernel.org
Subject: Aw: Re: [PATCH v1] ext2: fix datatype of block number in
 ext2_xattr_set2()

Hi,

Stephan noticed that the Format string of the debug message was not %lu - thats why i sent a PATCH v2.


> Gesendet: Mittwoch, den 16.08.2023 um 12:20 Uhr
> Von: "Jan Kara" <jack@...e.cz>
> An: "Andreas Dilger" <adilger@...ger.ca>
> Cc: "Georg Ottinger" <g.ottinger@....at>, jack@...e.com, linux-ext4@...r.kernel.org
> Betreff: 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