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]

Date:   Mon, 11 Jun 2018 14:28:57 +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 #2 from Wen Xu (wen.xu@...ech.edu) ---
(In reply to Theodore Tso from comment #1)
> This replicates on v4.17, but it doesn't replicate with the tip of ext4.git
> tree (which was pulled by Linus during the post 4.17 merge window).
> 
> Still TBD which of the patches fixes this particular POC replication.

Hi Ted,
In fact I reproduce with latest ext4 dev branch while fuzzing with Linus'
branch.
The last commit of the ext4.git branch I use to reproduce is
commit 4f2f76f751433908364ccff82f437a57d0e6e9b7
Author: Jan Kara <jack@...e.cz>
Date:   Fri May 25 12:51:25 2018 -0400

    ext4: fix fencepost error in check for inode count overflow during resize

    ext4_resize_fs() has an off-by-one bug when checking whether growing of
    a filesystem will not overflow inode count. As a result it allows a
    filesystem with 8192 inodes per group to grow to 64TB which overflows
    inode count to 0 and makes filesystem unusable. Fix it.

    Cc: stable@...r.kernel.org
    Fixes: 3f8a6411fbada1fa482276591e037f3b1adcf55b
    Reported-by: Jaco Kroon <jaco@....co.za>
    Signed-off-by: Jan Kara <jack@...e.cz>
    Signed-off-by: Theodore Ts'o <tytso@....edu>
    Reviewed-by: Andreas Dilger <adilger@...ger.ca>

And I can still get the following information with POC:

[  159.253263] EXT4-fs (loop0): mounted filesystem with ordered data mode.
Opts: (null)
[  160.963191]
==================================================================
[  160.964784] BUG: KASAN: slab-out-of-bounds in
ext4_xattr_list_entries+0x120/0x190
[  160.966274] Read of size 4 at addr ffff8801e33d3080 by task a.out/1348

[  160.967882] CPU: 0 PID: 1348 Comm: a.out Not tainted 4.17.0-rc4+ #5
[  160.967886] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  160.967889] Call Trace:
[  160.967901]  dump_stack+0x7b/0xb5
[  160.967913]  print_address_description+0x70/0x290
[  160.967919]  kasan_report+0x291/0x390
[  160.967926]  ? ext4_xattr_list_entries+0x120/0x190
[  160.967933]  __asan_load4+0x78/0x80
[  160.967940]  ext4_xattr_list_entries+0x120/0x190
[  160.967947]  ext4_listxattr+0x32e/0x5f0
[  160.967955]  ? ext4_xattr_get+0x4d0/0x4d0
[  160.967961]  ? __kmalloc_node+0x11e/0x2e0
[  160.967967]  ? ext4_xattr_get+0x4d0/0x4d0
[  160.967975]  vfs_listxattr+0x9d/0xc0
[  160.967981]  listxattr+0x58/0xd0
[  160.967988]  path_listxattr+0xb9/0x120
[  160.967994]  ? listxattr+0xd0/0xd0
[  160.968002]  ? vm_brk+0x20/0x20
[  160.968009]  __x64_sys_listxattr+0x48/0x50
[  160.968017]  do_syscall_64+0x78/0x170
[  160.968027]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  160.968031] RIP: 0033:0x7ff483fe20d7
[  160.968035] RSP: 002b:00007ffd3a2bc418 EFLAGS: 00000206 ORIG_RAX:
00000000000000c2
[  160.968041] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007ff483fe20d7
[  160.968044] RDX: 0000000000000071 RSI: 00007ffd3a2bc440 RDI:
0000000000af7080
[  160.968047] RBP: 00007ffd3a2bc4c0 R08: 0000000000af7010 R09:
0000000000000000
[  160.968050] R10: 00000000000001ab R11: 0000000000000206 R12:
0000000000400550
[  160.968053] R13: 00007ffd3a2bc5c0 R14: 0000000000000000 R15:
0000000000000000

[  160.968377] Allocated by task 0:
[  160.969027] (stack is not available)

[  160.970057] Freed by task 0:
[  160.970650] (stack is not available)

[  160.971681] The buggy address belongs to the object at ffff8801e33d3080
                which belongs to the cache pid(250:lvm2-lvmetad.service) of
size 64
[  160.974417] The buggy address is located 0 bytes inside of
                64-byte region [ffff8801e33d3080, ffff8801e33d30c0)
[  160.976653] The buggy address belongs to the page:
[  160.977605] page:ffffea00078cf4c0 count:1 mapcount:0
mapping:0000000000000000 index:0xffff8801e33d3000
[  160.979440] flags: 0x2ffff0000000100(slab)
[  160.980260] raw: 02ffff0000000100 0000000000000000 ffff8801e33d3000
000000018020001f
[  160.981780] raw: dead000000000100 dead000000000200 ffff8801e0c2da40
ffff8801f3c7bb80
[  160.983305] page dumped because: kasan: bad access detected
[  160.984406] page->mem_cgroup:ffff8801f3c7bb80

[  160.985584] Memory state around the buggy address:
[  160.989718]  ffff8801e33d2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[  160.991161]  ffff8801e33d3000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
fc
[  160.992579] >ffff8801e33d3080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
fc
[  160.993997]                    ^
[  160.994660]  ffff8801e33d3100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
fc
[  160.996073]  ffff8801e33d3180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
fc
[  160.997486]
==================================================================
[  160.998913] Disabling lock debugging due to kernel taint

The POC is simplified. I do not know whether use my original POC can help to
reproduce but I attached.

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