logfs: GPF in logfs_alloc_inode

29 views
Skip to first unread message

Dmitry Vyukov

unread,
Nov 18, 2016, 5:10:16 AM11/18/16
to jo...@logfs.org, Prasad Joshi, lo...@logfs.org, LKML, Al Viro, linux-...@vger.kernel.org, syzkaller
Hello,

The following program triggers GPF in logfs_alloc_inode:
https://gist.githubusercontent.com/dvyukov/64a2113e4cb484d9b7e0ef4ff8a522d0/raw/fffdfb8b781ec758563e08765a258da71e6ff2a1/gistfile1.txt


general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 6602 Comm: a.out Not tainted 4.9.0-rc5+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88003604c400 task.stack: ffff880035380000
RIP: 0010:[<ffffffff82514115>] [< inline >] i_uid_write
./include/linux/fs.h:1469
RIP: 0010:[<ffffffff82514115>] [<ffffffff82514115>]
logfs_init_inode.isra.5+0x155/0x480 fs/logfs/inode.c:212
RSP: 0018:ffff880035387838 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8800640af9e0 RCX: 0000000000000000
RDX: 000000000000011b RSI: ffffffff8995e940 RDI: 00000000000008d8
RBP: ffff8800353878c0 R08: 00000000000004d0 R09: 0000000000000000
R10: 0000000000000006 R11: 0000000000000000 R12: ffff8800640afe00
R13: 1ffff10006a70f07 R14: 0000000000000000 R15: ffff88006b563700
FS: 0000000001b3b940(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8526a449de CR3: 0000000034106000 CR4: 00000000000006e0
Stack:
0000000041b58ab3 ffffffff894c4c0b ffffffff82513fc0 000000000000aa81
ffffffff819efe35 ffff88006a63a7ff 1ffff1000d4c7500 ffffe8ffffc18490
00000001819effad 0000000000000003 ffff88000000000c 0000000000000282
Call Trace:
[<ffffffff82514475>] logfs_alloc_inode+0x35/0x40 fs/logfs/inode.c:234
[<ffffffff81ade226>] alloc_inode+0x66/0x180 fs/inode.c:207
[<ffffffff81ae57de>] new_inode_pseudo+0x6e/0x190 fs/inode.c:889
[<ffffffff81ae5921>] new_inode+0x21/0x50 fs/inode.c:918
[<ffffffff82514986>] logfs_new_meta_inode+0x26/0x120 fs/logfs/inode.c:267
[<ffffffff82533f97>] logfs_init_mapping+0x47/0x160 fs/logfs/segment.c:912
[< inline >] logfs_read_sb fs/logfs/super.c:446
[< inline >] logfs_get_sb_device fs/logfs/super.c:546
[<ffffffff825375f0>] logfs_mount+0x690/0x1e50 fs/logfs/super.c:600
[<ffffffff81a7d62c>] mount_fs+0x9c/0x2e0 fs/super.c:1177
[<ffffffff81af4e9c>] vfs_kern_mount.part.22+0x6c/0x2f0 fs/namespace.c:954
[< inline >] vfs_kern_mount fs/namespace.c:2433
[< inline >] do_new_mount fs/namespace.c:2436
[<ffffffff81afe3dd>] do_mount+0x41d/0x2db0 fs/namespace.c:2758
[< inline >] SYSC_mount fs/namespace.c:2974
[<ffffffff81b016d0>] SyS_mount+0xb0/0x120 fs/namespace.c:2951
[<ffffffff88147985>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 13 03 00 00 4c 8b 73 28 48 b8
00 00 00 00 00 fc ff df 49 8d be d8 08 00 00 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 e3 02 00 00 48 8d 7b 04 48 b8 00 00 00 00 00
RIP [< inline >] i_uid_write ./include/linux/fs.h:1469
RIP [<ffffffff82514115>] logfs_init_inode.isra.5+0x155/0x480
fs/logfs/inode.c:212
RSP <ffff880035387838>
---[ end trace a44003de9322a2bc ]---
LogFS: Start mount 1
==================================================================
BUG: KASAN: use-after-free in
__rwsem_down_write_failed_common+0xde7/0xf90 at addr ffff88003604c430
Read of size 4 by task a.out/6605
CPU: 1 PID: 6605 Comm: a.out Tainted: G B D 4.9.0-rc5+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88003cf6f130 ffffffff834c2a59 ffffffff00000001 1ffff100079eddb9
ffffed00079eddb1 0000000041b58ab3 ffffffff895758d0 ffffffff834c276b
ffffffff894f179e ffffffff815774c0 ffff88003cf6eff0 dffffc0000000000
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff834c2a59>] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
[<ffffffff819f09f1>] kasan_object_err+0x21/0x70 mm/kasan/report.c:159
[< inline >] print_address_description mm/kasan/report.c:197
[< inline >] kasan_report_error mm/kasan/report.c:286
[<ffffffff819f0cdb>] kasan_report+0x1eb/0x4c0 mm/kasan/report.c:306
[<ffffffff819f1009>] __asan_report_load4_noabort+0x19/0x20
mm/kasan/report.c:331
[< inline >] rwsem_optimistic_spin kernel/locking/rwsem-xadd.c:339
[<ffffffff8157a567>] __rwsem_down_write_failed_common+0xde7/0xf90
kernel/locking/rwsem-xadd.c:470
[<ffffffff881426f3>] rwsem_down_write_failed+0x13/0x20
kernel/locking/rwsem-xadd.c:555
[<ffffffff83504657>] call_rwsem_down_write_failed+0x17/0x30
arch/x86/lib/rwsem.S:105
[< inline >] __down_write ./arch/x86/include/asm/rwsem.h:125
[<ffffffff88140a4c>] down_write+0xac/0x120 kernel/locking/rwsem.c:54
[<ffffffff81a79bc8>] grab_super+0xa8/0x290 fs/super.c:364
[<ffffffff81a7ab58>] sget_userns+0x1f8/0xd40 fs/super.c:491
[<ffffffff81a7b764>] sget+0xc4/0x100 fs/super.c:548
[< inline >] logfs_get_sb_device fs/logfs/super.c:522
[<ffffffff825372ee>] logfs_mount+0x38e/0x1e50 fs/logfs/super.c:600
[<ffffffff81a7d62c>] mount_fs+0x9c/0x2e0 fs/super.c:1177
[<ffffffff81af4e9c>] vfs_kern_mount.part.22+0x6c/0x2f0 fs/namespace.c:954
[< inline >] vfs_kern_mount fs/namespace.c:2433
[< inline >] do_new_mount fs/namespace.c:2436
[<ffffffff81afe3dd>] do_mount+0x41d/0x2db0 fs/namespace.c:2758
[< inline >] SYSC_mount fs/namespace.c:2974
[<ffffffff81b016d0>] SyS_mount+0xb0/0x120 fs/namespace.c:2951
[<ffffffff88147985>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Object at ffff88003604c400, in cache task_struct size: 5632
Allocated:
PID = 6598
[ 204.878017] [<ffffffff8127101b>] save_stack_trace+0x1b/0x20
[ 204.878017] [<ffffffff819efce3>] save_stack+0x43/0xd0
[ 204.878017] [<ffffffff819effad>] kasan_kmalloc+0xad/0xe0
[ 204.878017] [<ffffffff819f0582>] kasan_slab_alloc+0x12/0x20
[ 204.878017] [<ffffffff819e9b48>] kmem_cache_alloc_node+0x138/0x740
[ 204.878017] [<ffffffff813f63a5>] copy_process.part.38+0x1995/0x4920
[ 204.878017] [<ffffffff813f9825>] _do_fork+0x205/0x1070
[ 204.878017] [<ffffffff813fa76c>] SyS_clone+0x3c/0x50
[ 204.878017] [<ffffffff81009a24>] do_syscall_64+0x2f4/0x940
[ 204.878017] [<ffffffff88147a4d>] return_from_SYSCALL_64+0x0/0x7a
Freed:
PID = 0
[ 204.878017] [<ffffffff8127101b>] save_stack_trace+0x1b/0x20
[ 204.878017] [<ffffffff819efce3>] save_stack+0x43/0xd0
[ 204.878017] [<ffffffff819f0602>] kasan_slab_free+0x72/0xc0
[ 204.878017] [<ffffffff819ed5ab>] kmem_cache_free+0x7b/0x2f0
[ 204.878017] [<ffffffff813f3504>] free_task+0x114/0x190
[ 204.878017] [<ffffffff813f37d8>] __put_task_struct+0x258/0x610
[ 204.878017] [<ffffffff8140a024>] delayed_put_task_struct+0xe4/0x4b0
[ 204.878017] [<ffffffff815cbced>] rcu_do_batch.isra.70+0x9ed/0xe20
[ 204.878017] [<ffffffff815cc5ac>] rcu_process_callbacks+0x48c/0xd70
[ 204.878017] [<ffffffff8814b0fb>] __do_softirq+0x32b/0xca8
Memory state around the buggy address:
ffff88003604c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88003604c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88003604c400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88003604c480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88003604c500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


On commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5).

Omar Sandoval

unread,
Nov 18, 2016, 1:45:44 PM11/18/16
to Dmitry Vyukov, Christoph Hellwig, jo...@logfs.org, Prasad Joshi, lo...@logfs.org, LKML, Al Viro, linux-...@vger.kernel.org, syzkaller
On Fri, Nov 18, 2016 at 11:09:54AM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in logfs_alloc_inode:
> https://gist.githubusercontent.com/dvyukov/64a2113e4cb484d9b7e0ef4ff8a522d0/raw/fffdfb8b781ec758563e08765a258da71e6ff2a1/gistfile1.txt

That should be fixed by this patch:
http://marc.info/?l=linux-kernel&m=147359909329298&w=2 ;)

--
Omar

Dmitry Vyukov

unread,
Nov 18, 2016, 1:54:27 PM11/18/16
to syzkaller, Christoph Hellwig, jo...@logfs.org, Prasad Joshi, lo...@logfs.org, LKML, Al Viro, linux-...@vger.kernel.org
Nice!

When will it merged into mainline?

Dmitry Vyukov

unread,
Nov 20, 2016, 4:57:37 AM11/20/16
to syzkaller, Christoph Hellwig, jo...@logfs.org, Prasad Joshi, lo...@logfs.org, LKML, Al Viro, linux-...@vger.kernel.org
Yes, delivery to jo...@logfs.org and lo...@logfs.org fails.

Richard Weinberger

unread,
Nov 20, 2016, 4:05:17 PM11/20/16
to Dmitry Vyukov, syzkaller, Christoph Hellwig, Jörn Engel, Prasad Joshi, lo...@logfs.org, LKML, Al Viro, linux-...@vger.kernel.org
Wasn't the plan to remove logfs?

--
Thanks,
//richard

Omar Sandoval

unread,
Nov 20, 2016, 6:48:09 PM11/20/16
to Richard Weinberger, Dmitry Vyukov, syzkaller, Christoph Hellwig, Prasad Joshi, LKML, Al Viro, linux-...@vger.kernel.org
Yes, that's the patch I linked to.

--
Omar
Reply all
Reply to author
Forward
0 new messages