linux-ext4 - [Bug 199403] use-after-free in ext4_ext_remove_space() 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-199403-13602-KZzz1am9fA@https.bugzilla.kernel.org/>
Date:   Thu, 14 Jun 2018 05:15:35 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 199403] use-after-free in ext4_ext_remove_space() when mounting
 and operating a crafted ext4 image

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |tytso@....edu

--- Comment #3 from Theodore Tso (tytso@....edu) ---
There is a completely issue with the latest Linux tree.  (I suspect the earlier
UAF was fixed recent fix.)

As far as the latest UAF is concerned, this is triggered by the fact that
allocation bitmaps are marked as uninitialized for block group #0.  Ext4
shouldn't have paid attention to these flags, since the prerequisite file
system feature (uninit_bg or metadata_csum) was not set.  In addition, even if
one of those two feature flags were set, ext4 should report an file system
corruption if bitmaps for bg 0 are marked as uninitialized and refuse to try to
clear those bitmaps, since nothing good can happen.

This will be fixed by the patch:

    ext4: only look at the bg_flags field if it is valid

    The bg_flags field in the block group descripts is only valid if the
    uninit_bg or metadata_csum feature is enabled.  We were not
    consistently looking at this field; fix this.

    Also block group #0 must never have uninitialized allocation bitmaps,
    or need to be zeroed, since that's where the root inode, and other
    special inodes are set up.  Check for these conditions and mark the
    file system as corrupted if they are detected.

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