linux-ext4 - [Bug 199977] ext4: use-after-free() detected by KASAN 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-199977-13602-VrNeVdptJt@https.bugzilla.kernel.org/>
Date:   Wed, 13 Jun 2018 04:49:54 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 199977] ext4: use-after-free() detected by KASAN when mounting
 and operating a crafted ext4 image

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

--- Comment #4 from Theodore Tso (tytso@....edu) ---
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
bug.

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.