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  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]
Date:   Sun, 20 Jan 2019 12:35:50 +0100
From:   Etienne Buira <>
Subject: Re: ext4fs block role, debugfs testb and icheck mismatch

On Wed, Jan 16, 2019 at 10:34:23PM +0100, Etienne Buira wrote:
> For the background: i've hit defect sectors (on part of md array), and i
> want to rewrite those sectors to force hdd reallocation, so i need to
> figure out what they are used for.


I could resolve my issue, i was wrong on block number.

What's left is the weird behaviour of debugfs, which reports a given
block as "in use", and not linked to any inode (although it is in data

> Unrolling the layers under fs, i'm interested in a 4K blocks range that
> starts at 2035, here starts the trouble:
> debugfs 1.43.9 (8-Feb-2018)
> debugfs:  testb 2035
> Block 2035 marked in use
> debugfs:  icheck 2035
> Block   Inode number
> 2035    <block not found>
> From this result, i tried to figure out if this block were used for fs
> internal structures.
> Using dumpe2fs, i see that this block belongs to group 0, and falls
> beyond fs structures (last block for inode table is reported as 1568).
> Block 2035 is not reported as free blocks.

The debugfs queries have been done multiple times, so it is quite
unprobable fs allocated this block everytime before i issued testb,
and released it by the time i issued icheck.


Powered by blists - more mailing lists