linux-ext4 - Fwd: meta_bg descriptor backup calculation bug

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

Date:	Mon, 5 Oct 2015 09:07:41 -0700
From:	Andy Leiserson <andy@...serson.org>
To:	linux-ext4@...r.kernel.org
Subject: Fwd: meta_bg descriptor backup calculation bug

Just sent a patch related to this. Some more background:

I observed this on a 1K block filesystem that I resized from 16 GB to
24 GB. Prior to the resize there were no remaining reserved GDT
blocks.

Possibly related to this issue, or possibly due to unrelated
corruption, the filesystem errored and remounted read only. I rebooted
and fsck'ed and discovered the corruption to be substantial.
Unfortunately I don't have a block-level backup of the original state
of the filesystem, the errors from before the reboot, or a log of what
the initial fsck did. (I don't think that I let it do much, if
anything, more than try to replay the journal, which was not
successful.)

What I found in debugfs was that:
* The descriptor data for groups 0..31 instead described groups 3040..3071.
* The descriptor data for groups 2048..3071 was zero'ed (except checksum)

The first bullet is what gave me the idea that the new descriptors
were being written in the wrong place. But I don't have a solid
explanation for the second bullet.

I tried similar resizes to the original with debugging enabled before
and after my proposed fix, and the "updating metadata backup" messages
are consistent with the explanation. Before the fix, every meta_bg
backup goes to blocks 8194 and 253953. 8194 is a backup copy of the
first descriptor block, explaining why groups 0..31 were overwritten
(assuming fsck tried to use the first backup copy). 253953 contains a
block bitmap, and doing an fsck immediately after the resize finds a
bunch of block bitmap inconsistencies.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html