linux-ext4 - Re: ext4_validate_block_bitmap regression on ext3 with stride=X

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-prev] [day] [month] [year] [list]

Message-ID: <20180424090149.lef4wrdu3pzxnk76@rh_laptop>
Date:   Tue, 24 Apr 2018 11:01:49 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     Ilya Dryomov <idryomov@...il.com>
Cc:     linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu>
Subject: Re: ext4_validate_block_bitmap regression on ext3 with stride=X

On Thu, Apr 19, 2018 at 08:50:43PM +0200, Ilya Dryomov wrote:
> Hello,
> 
> Commit 7dac4a1726a9 ("ext4: add validity checks for bitmap block
> numbers") in 4.17-rc1 causes a regression on ext3 with a custom
> stride-size.  One of the new checks triggers, sometimes leading to
> transient -ENOSPC errors that go away after a remount.
> 
> Trivially reproduced with:
> 
>   $ mkfs -t ext3 -E stride=256 /dev/vdb
>   $ mount /dev/vdb /mnt
>   $ cd /mnt
>   $ wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz
>   $ tar xvf linux-4.16.3.tar.xz

Thanks for the report, the problem is in this check

EXT4_B2C(sbi, offset) >= sb->s_blocksize

which is used several times in the ext4_valid_block_bitmap() and
implies that the bitmap needs to be placed within first s_blocksize
blocks of the block group. But that's not true. It can be placed
anywhere in the block group either due to stride, or I believe even
due to badblocks. I am sure there are other reasons to put bitmaps
further in the block group.

The fix would be to check whether the bitmap is contained withing the
block group, hence the test_bit will not attempt to check outside the
size of the b_data.

I'll prepare a patch.

-Lukas

> 
> [ 2769.383365] EXT4-fs (vdb): mounting ext3 file system using the ext4 subsystem
> [ 2769.392635] EXT4-fs (vdb): mounted filesystem with ordered data
> mode. Opts: (null)
> [ 2791.127834] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 14: block 462848: invalid
> block bitmap
> [ 2791.130456] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 15: block 495872: invalid
> block bitmap
> [ 2791.133257] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 16: block 528896: invalid
> block bitmap
> [ 2791.137147] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 17: block 561920: invalid
> block bitmap
> [ 2791.139943] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 18: block 594944: invalid
> block bitmap
> [ 2791.142342] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 20: block 660992: invalid
> block bitmap
> [ 2791.145348] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 21: block 694016: invalid
> block bitmap
> [ 2791.148161] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 22: block 727040: invalid
> block bitmap
> [ 2791.150702] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 23: block 760064: invalid
> block bitmap
> [ 2791.153333] EXT4-fs error (device vdb):
> ext4_validate_block_bitmap:399: comm tar: bg 24: block 793088: invalid
> block bitmap
> 
> Reverting 7dac4a1726a9 fixes it for me.
> 
> Thanks,
> 
>                 Ilya