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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Jun 2018 04:49:54 +0000
Subject: [Bug 199977] ext4: use-after-free() detected by KASAN when mounting
 and operating a crafted ext4 image

--- Comment #4 from Theodore Tso ( ---
The original POC and your simplified POC bug are catching different problems. 
Part of the reason for this is that your fuzzed image has many different file
system corruptions.  So for example, inode #7 is completely corrupted in some
strange way that causes e2fsck to not be able to fix file system at all.  The
kernel problems are triggered by it still trigger if you use debugfs to "clri
<7>".   This makes it harder for me to figure out what was the specific file
system corruption that was causing the problem being reported in a specific

So with the simplified poc, I'm no longer seeing a problem with the tip of the
ext4 branch because the simplified poc is only testing ext4's handling a
specific corruption, and that's now fixed:

[   32.516640] EXT4-fs error (device loop0): ext4_xattr_ibody_find:2191: inode
#14: comm poc-199997: corrupted in-inode xattr

With your full POC, we're now tripping on the block 35 problem.  I have a fix
for it that I fixed for Bugzilla #200001, and I'm finding that one of the
patches that I used to fix that problem also now fixes Bugzilla #19997, and it
also fixes Bugzilla #199977 with your expanded poc.c:

[   26.736417] EXT4-fs error (device loop0): ext4_xattr_block_list:708: inode
#15: comm poc-199977: corrupted xattr block 35

The specific problem here is that 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)".

So now we get to an interesting philosophical question --- is the kernel bug
fundamentally about the fuzzed image, or the poc.c code that was submitted to
trigger the problem?   And if you have a fuzzed image with many many
corruptions, and a different poc.c is used to trigger kernel bug related to a
different aspect of the image corruption, and with a completely different
kernel signature, is it the same bug or a different bug?

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

Powered by blists - more mailing lists