| 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
| ||
|
Date: Mon, 01 Jul 2019 15:44:30 -0700 From: James Bottomley <James.Bottomley@...senPartnership.com> To: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org Cc: Parisc List <linux-parisc@...r.kernel.org> Subject: [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251 Background: we actually use the badblocks feature of the ext filesystem group to do a poorman's boot filesystem for parisc: Our system chunks up the disk searching for an Initial Program Loader (IPL) signature and then executes it, so we poke a hole in an ext3 filesystem at creation time and place the IPL into it. Our IP can read ext3 files and directories, so it allows us to load the kernel directly from the file. The problem is that our IPL needs to be aligned at 256k in absolute terms on the disk, so, in the usual situation of having a 64k partition label and the boot partition being the first one we usually end up poking the badblock hole beginning at block 224 (using a 1k block size). The problem is that this used to work long ago (where the value of long seems to be some time before 2011) but no longer does. The problem can be illustrated simply by doing --- # dd if=/dev/zero of=bbtest.img bs=1M count=100 # losetup /dev/loop0 bbtest.img # a=237; while [ $a -le 450 ]; do echo $a >> bblist.txt; a=$[$a+1]; done # mke2fs -b 1024 -l /home/jejb/bblist.txt /dev/loop0 --- Now if you try to do an e2fsck on the partition you'll get this --- # e2fsck -f /dev/loop0 e2fsck 1.45.2 (27-May-2019) Pass 1: Checking inodes, blocks, and sizes Programming error? block #237 claimed for no reason in process_bad_block. Programming error? block #238 claimed for no reason in process_bad_block. Programming error? block #239 claimed for no reason in process_bad_block. Programming error? block #240 claimed for no reason in process_bad_block. Programming error? block #241 claimed for no reason in process_bad_block. Programming error? block #242 claimed for no reason in process_bad_block. Programming error? block #243 claimed for no reason in process_bad_block. Programming error? block #244 claimed for no reason in process_bad_block. Programming error? block #245 claimed for no reason in process_bad_block. Programming error? block #246 claimed for no reason in process_bad_block. Programming error? block #247 claimed for no reason in process_bad_block. Programming error? block #248 claimed for no reason in process_bad_block. Programming error? block #249 claimed for no reason in process_bad_block. Programming error? block #250 claimed for no reason in process_bad_block. Programming error? block #251 claimed for no reason in process_bad_block. Programming error? block #252 claimed for no reason in process_bad_block. Programming error? block #253 claimed for no reason in process_bad_block. Programming error? block #254 claimed for no reason in process_bad_block. Programming error? block #255 claimed for no reason in process_bad_block. Programming error? block #256 claimed for no reason in process_bad_block. Programming error? block #257 claimed for no reason in process_bad_block. Programming error? block #258 claimed for no reason in process_bad_block. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #0 (7556, counted=7578). Fix<y>? --- So mke2fs has created an ab-inito corrupt filesystem. Empirically, this only seems to happen if there is a block in the bad block list under 251, but I haven't verified this extensively. James
Powered by blists - more mailing lists