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
| ||
|
Message-ID: <9aa773bd-44e8-4e4b-9628-dfbd3bd0a2af@huawei.com> Date: Thu, 26 Sep 2024 22:35:03 +0800 From: Baokun Li <libaokun1@...wei.com> To: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com> CC: Jan Kara <jack@...e.cz>, <tytso@....edu>, <stable@...r.kernel.org>, Andreas Dilger <adilger.kernel@...ger.ca>, Stéphane Graber <stgraber@...raber.org>, Christian Brauner <brauner@...nel.org>, <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>, Wesley Hershberger <wesley.hershberger@...onical.com>, Yang Erkun <yangerkun@...wei.com> Subject: Re: [PATCH 1/1] ext4: fix crash on BUG_ON in ext4_alloc_group_tables On 2024/9/26 22:19, Aleksandr Mikhalitsyn wrote: > On Thu, Sep 26, 2024 at 3:58 PM Baokun Li <libaokun1@...wei.com> wrote: >> On 2024/9/26 19:32, Aleksandr Mikhalitsyn wrote: >>>>> Question to you and Jan. Do you guys think that it makes sense to try >>>>> to create a minimal reproducer for this problem without Incus/LXD involved? >>>>> (only e2fsprogs, lvm tools, etc) >>>>> >>>>> I guess this test can be put in the xfstests test suite, right? >>>>> >>>>> Kind regards, >>>>> Alex >>>> I think it makes sense, and it's good to have more use cases to look >>>> around some corners. If you have an idea, let it go. >>> Minimal reproducer: >>> >>> mkdir -p /tmp/ext4_crash/mnt >>> EXT4_CRASH_IMG="/tmp/ext4_crash/disk.img" >>> rm -f $EXT4_CRASH_IMG >>> truncate $EXT4_CRASH_IMG --size 25MiB >>> EXT4_CRASH_DEV=$(losetup --find --nooverlap --direct-io=on --show >>> $EXT4_CRASH_IMG) >>> mkfs.ext4 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $EXT4_CRASH_DEV >>> mount $EXT4_CRASH_DEV /tmp/ext4_crash/mnt >>> truncate $EXT4_CRASH_IMG --size 3GiB >>> losetup -c $EXT4_CRASH_DEV >>> resize2fs $EXT4_CRASH_DEV >>> >> Hi Alex, >> >> This replicator didn't replicate the issue in my VM, so I took a deeper >> look. The reproduction of the problem requires the following: > That's weird. Have just tried once again and it reproduces the issue: > > root@...ntu:/home/ubuntu# mkdir -p /tmp/ext4_crash/mnt > EXT4_CRASH_IMG="/tmp/ext4_crash/disk.img" > rm -f $EXT4_CRASH_IMG > truncate $EXT4_CRASH_IMG --size 25MiB > EXT4_CRASH_DEV=$(losetup --find --nooverlap --direct-io=on --show > $EXT4_CRASH_IMG) > mkfs.ext4 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $EXT4_CRASH_DEV > mount $EXT4_CRASH_DEV /tmp/ext4_crash/mnt > truncate $EXT4_CRASH_IMG --size 3GiB > losetup -c $EXT4_CRASH_DEV > resize2fs $EXT4_CRASH_DEV > mke2fs 1.47.0 (5-Feb-2023) > Creating filesystem with 6400 4k blocks and 6400 inodes > > Allocating group tables: done > Writing inode tables: done > Creating journal (1024 blocks): done > Writing superblocks and filesystem accounting information: done > > resize2fs 1.47.0 (5-Feb-2023) > Filesystem at /dev/loop4 is mounted on /tmp/ext4_crash/mnt; on-line > resizing required > old_desc_blocks = 1, new_desc_blocks = 1 I can see why, on my side I mkfsed a 25M sized disk, and the ext4 block size is 1024 by default, whereas on your side it's 4096. I set the block size to 4096 and it also reproduced the issue. Thanks for your feedback! Cheers, Baokun
Powered by blists - more mailing lists