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

--- Comment #2 from Theodore Tso ( ---
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()

ext4: always verify the magic number in xattr blocks

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.

Powered by blists - more mailing lists