linux-ext4 - kernel BUG at fs/ext4/inode.c:3709! (Re: open bugs found by fuzzing)

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: <5788E787.106@oracle.com>
Date:	Fri, 15 Jul 2016 15:39:19 +0200
From:	Vegard Nossum <vegard.nossum@...cle.com>
To:	linux-ext4@...r.kernel.org, Michael Halcrow <mhalcrow@...gle.com>
Cc:	Ildar Muslukhov <ildarm@...gle.com>,
	Jaegeuk Kim <jaegeuk@...nel.org>
Subject: kernel BUG at fs/ext4/inode.c:3709! (Re: open bugs found by fuzzing)

On 07/14/2016 11:10 PM, Vegard Nossum wrote:
> 3. kernel BUG at fs/ext4/inode.c:3709!
> http://139.162.151.198/f/ext4/5bdefda69f39b2f2c56d9b67d5b7d9e2cc8dfd5f

I don't see any evidence of memory corruption here, so this one seems
pretty straightforward: we have an encrypted orphan inode and when we
try to truncate it during the orphan list cleanup it results in a BUG
because we haven't loaded the encryption key for it.

The inode in question has ->i_ino == 16 so I don't think this has
anything to do with special inodes.

Something quick and dirty like this does solve the BUG_ON() for me, but
it looks a lot like papering over an underlying bug:

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5a6277d..794b33a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3735,9 +3735,11 @@ static int __ext4_block_zero_page_range(handle_t 
*handle,
  		if (S_ISREG(inode->i_mode) &&
  		    ext4_encrypted_inode(inode)) {
  			/* We expect the key to be set. */
-			BUG_ON(!fscrypt_has_encryption_key(inode));
-			BUG_ON(blocksize != PAGE_SIZE);
-			WARN_ON_ONCE(fscrypt_decrypt_page(page));
+		        if (list_empty(&EXT4_I(inode)->i_orphan)) {
+				BUG_ON(!fscrypt_has_encryption_key(inode));
+				BUG_ON(blocksize != PAGE_SIZE);
+				WARN_ON_ONCE(fscrypt_decrypt_page(page));
+			}
  		}
  	}
  	if (ext4_should_journal_data(inode)) {

I'm a bit puzzled that we're actually creating a mapping and trying to
decrypt here in the first place, since if this is an orphan inode that
is being recovered at mount time it means that we know _for sure_ that
there is no existing memory mappings and we're truncating it to 0.

Anyway, adding some Ccs.

Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html