linux-ext4 - [Bug 200001] use-after-free detected by KASAN in ext4_xattr_set_entry when renaming a file in 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]

Date:   Wed, 13 Jun 2018 16:14:39 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200001] use-after-free detected by KASAN in
 ext4_xattr_set_entry when renaming a file in a crafted ext4 image

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

--- Comment #2 from Theodore Tso (tytso@....edu) ---
The fundamental problem block 35 is being used as a block allocation bitmap. 
On a number of your fuzzed images, one or more of the inodes use that same
block as an external xattr block.   So the problem is that block 35 is verified
as an allocation bitmap; and then the buffer_verified flag is set.  Then when
we call ext4_xattr_check_block(), the code looks at the buffer_verified flag,
and says, "Hurr durr.... this block has already been verified (as an allocation
bitmap) so it must be OK; no need to verify it again (as an xattr block)".

I have two patches to address this:

ext4: add corruption check in ext4_xattr_set_entry()
    http://patchwork.ozlabs.org/patch/928666/

ext4: always verify the magic number in xattr blocks
    http://patchwork.ozlabs.org/patch/928667/

The first patch is sufficient to fix both this bug and #199997 by adding an
sanity check in ext4_xattr_set_entry --- so that we're not dependent on
verifying that xattr block is sane.  However, there are a number of other
places in fs/ext4/xattr.c where it's too hard to make sure extended attributes
don't overrun the block boundaries without doing massive code restructuring. 

So the second patch fixes the problem where the block was marked as verified
via as a different metadata block type and then trying to treat that block as
an xattr block.

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