linux-ext4 - [Bug 200005] BUG() triggered in ext4_update_inline_data() when mounting and writing to 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]

Message-ID: <bug-200005-13602-lhYkQh5haI@https.bugzilla.kernel.org/>
Date:   Sun, 10 Jun 2018 04:24:19 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200005] BUG() triggered in ext4_update_inline_data() when
 mounting and writing to a crafted ext4 image

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

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #1 from Theodore Tso (tytso@....edu) ---
Part of what is going on here is that there is an extended attribute for
system.data stored in the inode in question, but the subsequent extended
attribute is corrupted.   The next problem is that the struct superblock has a
required isize of 84, so this triggers an attempt to allocate an external xattr
block to move some of the xattrs out.   Then we try to allocate a block, and
the block allocation bitmaps are corrupted, so the block allocation fails.

Somewhere along this whole mess, we lose system.data extended attribute, which
is why the subsequent write isn't able to find it, thus triggering the
BUG_ON(is.s.not_found)

So one or more of the various error handling isn't handling the errors=continue
case correctly.   Definitely a case of an extremely maliciously crafted file
system!

>From debugfs's stats command:

Required extra isize:     84
Desired extra isize:      32

debugfs:  stat <14>
Inode: 14   Type: regular    Mode:  0644   Flags: 0x10000000
Generation: 3064322158    Version: 0x00000000:00000001
User:     0   Group:     0   Project:     0   Size: 11
File ACL: 0
Links: 2   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5b189273:ba993a5c -- Wed Jun  6 22:03:31 2018
 atime: 0x5b189273:b9a515a0 -- Wed Jun  6 22:03:31 2018
 mtime: 0x5b189273:b9a515a0 -- Wed Jun  6 22:03:31 2018
crtime: 0x5b189273:b9a515a0 -- Wed Jun  6 22:03:31 2018
Size of extra inode fields: 32
debugfs:  id -e <14>
0000  0000 02ea 0407 0000 0000 0000 0000 0000  ................
0020  0000 0000 6461 7461 02e8 0300 0000 ffff  ....data........
0040  ff7f 0000 0000 0000 0000 0000 0000 0000  ................
0060  0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0120  0000 0000 0000 0000 0000 0000 0000 fffd  ................

debugfs:  id -b <14>
0000  6865 6c6c 6f20 776f 726c 6400 0000 0000  hello world.....
0020  0000 0000 0000 0000 0000 0000 0000 0000  ................
*

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