linux-ext4 - [Bug 200015] BUG() triggered in ext4_get_group_info() when mounting and operating a crafted ext4 image

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

Message-ID: <bug-200015-13602-WSuqgBJmof@https.bugzilla.kernel.org/>
Date:   Thu, 14 Jun 2018 23:30:08 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200015] BUG() triggered in ext4_get_group_info() when mounting
 and operating a crafted ext4 image

https://bugzilla.kernel.org/show_bug.cgi?id=200015

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #2 from Theodore Tso (tytso@....edu) ---
Thanks for the simplified POC.  But unfortunately that doesn't really tell me
anything new.  What I need is a simplified POC *image*.

I can add a simplistic check to see if we get a negative group number in
ext4_discard_preallocations(), but that's not the real root cause.  And it
wouldn't be a complete solution, since we would have add gazillions of checks
anywhere we use s_first_data_block.    It's much better if we can check
s_first_data_block at mount time (which we do), and then make sure that it
can't get corrupted afterwards.

So the real root cause is somehow, the superblock buffer has gotten corrupted. 
 We have a lot of checks to prevent this from happening --- that's what the
ext4_data_block_valid() function in fs/ext4/block_validity.c is all about ---
but obviously, we're missing a check somewhere.   The question is where.   If
we had a simplified POC image, I could look to find the file system corruption
that was causing the superblock to get trashed.   The problem is that there are
so many random corruptions, many of them completely irrelevant to the bug at
hand, that this is extremely difficult.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.