New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 631945 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
█ dvyukov@chromium.org
drinkcat@chromium.org
█ dtor@chromium.org
groeck@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

KASAN reports use-after-free errors in vmacache_find, unmapped_area_topdown and vma_gap_callbacks_propagate on 4.4

Project Member Reported by glider@chromium.org, Jul 27 2016 
The following error has been reported on a 4.4 kernel built with KASAN and running under syzkaller. No reproducer so far (the bug is in crash_reporter):

==================================================================
BUG: KASAN: use-after-free in vmacache_find+0x11a/0x1a3 at addr ffff88000801c130
Read of size 8 by task crash_reporter/18575
CPU: 3 PID: 18575 Comm: crash_reporter Tainted: G    B           4.4.14 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 00000000ffffffff 00000000a1e343e8 ffff88004a277dd8 ffffffff813e2288
 ffffffff00000040 ffff8800519bad40 ffffed0001003826 ffff88000801c1a0
 ffff88004a277e20 ffffffff811e9610 0000000000000296 1ffff10001003826
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff813e2288>] dump_stack+0x71/0x94 lib/dump_stack.c:51
 [<     inline     >] object_err mm/kasan/report.c:139
 [<     inline     >] print_address_description mm/kasan/report.c:180
 [<     inline     >] kasan_report_error mm/kasan/report.c:277
 [<ffffffff811e9610>] kasan_report+0x308/0x55e mm/kasan/report.c:300
 [<     inline     >] ? __raw_spin_unlock include/linux/spinlock_api_smp.h:154
 [<ffffffff81d0adfc>] ? _raw_spin_unlock+0x1e/0x20 kernel/locking/spinlock.c:183
 [<ffffffff811c81ed>] ? handle_mm_fault+0x11db/0x1247 mm/memory.c:3506
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:272
 [<ffffffff811e8731>] __asan_load8+0x64/0x66 mm/kasan/kasan.c:710
 [<ffffffff811bd0f3>] vmacache_find+0x11a/0x1a3 mm/vmacache.c:100
 [<ffffffff811cab3c>] find_vma+0x26/0xcb mm/mmap.c:2070
 [<ffffffff8105e0ad>] __do_page_fault+0x285/0x54c arch/x86/mm/fault.c:1201
 [<ffffffff8105e3c4>] do_page_fault+0x25/0x27 arch/x86/mm/fault.c:1308
 [<ffffffff81d0cf62>] page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1019
Object at ffff88000801c0f0, in cache vm_area_struct
Object allocated with size 176 bytes.
Allocation:
PID = 18575
 [<ffffffff810175c7>] save_stack_trace+0x2b/0x46 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811e8455>] save_stack+0x46/0xce mm/kasan/kasan.c:456
 [<     inline     >] set_track mm/kasan/kasan.c:468
 [<ffffffff811e8b7d>] kasan_kmalloc+0xaf/0xbe mm/kasan/kasan.c:566
 [<ffffffff811e8f0d>] kasan_slab_alloc+0x12/0x14 mm/kasan/kasan.c:488
 [<ffffffff811e6cdb>] kmem_cache_alloc+0x87/0x106 mm/slab.c:3397
 [<     inline     >] kmem_cache_zalloc include/linux/slab.h:598
 [<     inline     >] __bprm_mm_init fs/exec.c:263
 [<     inline     >] bprm_mm_init fs/exec.c:380
 [<ffffffff81205297>] do_execveat_common.isra.37+0x536/0xbd0 fs/exec.c:1566
 [<ffffffff81205968>] do_execve+0x37/0x40 fs/exec.c:1639
 [<ffffffff8108ee86>] call_usermodehelper_exec_async+0x1b5/0x218 kernel/kmod.c:252
 [<ffffffff81d0b5ef>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:502
Memory state around the buggy address:
 ffff88000801c000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88000801c080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb fb
>ffff88000801c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                     ^
 ffff88000801c180: fb fb fb fb fc fc fc fc fc fc fc fc 00 00 00 00
 ffff88000801c200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
==================================================================
BUG: KASAN: use-after-free in vmacache_find+0x12d/0x1a3 at addr ffff88000801c0f0
Read of size 8 by task crash_reporter/18575
CPU: 3 PID: 18575 Comm: crash_reporter Tainted: G    B           4.4.14 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 00000000ffffffff 00000000a1e343e8 ffff88004a277dd8 ffffffff813e2288
 ffffffff00000000 ffff8800519bad40 ffffed000100381e ffff88000801c1a0
 ffff88004a277e50 ffffffff811e9610 0000000000000296 1ffff1000100381e
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff813e2288>] dump_stack+0x71/0x94 lib/dump_stack.c:51
 [<     inline     >] object_err mm/kasan/report.c:139
 [<     inline     >] print_address_description mm/kasan/report.c:180
 [<     inline     >] kasan_report_error mm/kasan/report.c:277
 [<ffffffff811e9610>] kasan_report+0x308/0x55e mm/kasan/report.c:300
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:272
 [<ffffffff811e8731>] __asan_load8+0x64/0x66 mm/kasan/kasan.c:710
 [<ffffffff811bd106>] vmacache_find+0x12d/0x1a3 mm/vmacache.c:102
 [<ffffffff811cab3c>] find_vma+0x26/0xcb mm/mmap.c:2070
 [<ffffffff8105e0ad>] __do_page_fault+0x285/0x54c arch/x86/mm/fault.c:1201
 [<ffffffff8105e3c4>] do_page_fault+0x25/0x27 arch/x86/mm/fault.c:1308
 [<ffffffff81d0cf62>] page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1019
Object at ffff88000801c0f0, in cache vm_area_struct
Object allocated with size 176 bytes.
Allocation:
PID = 18575
 [<ffffffff810175c7>] save_stack_trace+0x2b/0x46 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811e8455>] save_stack+0x46/0xce mm/kasan/kasan.c:456
 [<     inline     >] set_track mm/kasan/kasan.c:468
 [<ffffffff811e8b7d>] kasan_kmalloc+0xaf/0xbe mm/kasan/kasan.c:566
 [<ffffffff811e8f0d>] kasan_slab_alloc+0x12/0x14 mm/kasan/kasan.c:488
 [<ffffffff811e6cdb>] kmem_cache_alloc+0x87/0x106 mm/slab.c:3397
 [<     inline     >] kmem_cache_zalloc include/linux/slab.h:598
 [<     inline     >] __bprm_mm_init fs/exec.c:263
 [<     inline     >] bprm_mm_init fs/exec.c:380
 [<ffffffff81205297>] do_execveat_common.isra.37+0x536/0xbd0 fs/exec.c:1566
 [<ffffffff81205968>] do_execve+0x37/0x40 fs/exec.c:1639
 [<ffffffff8108ee86>] call_usermodehelper_exec_async+0x1b5/0x218 kernel/kmod.c:252
 [<ffffffff81d0b5ef>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:502
Memory state around the buggy address:
 ffff88000801bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88000801c000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88000801c080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb fb
                                                             ^
 ffff88000801c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88000801c180: fb fb fb fb fc fc fc fc fc fc fc fc 00 00 00 00
==================================================================
==================================================================
BUG: KASAN: use-after-free in unmapped_area_topdown+0x11c/0x2ee at addr ffff88000801c108
Read of size 8 by task crash_reporter/18575
CPU: 3 PID: 18575 Comm: crash_reporter Tainted: G    B           4.4.14 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 00000000ffffffff 00000000a1e343e8 ffff88004a277c68 ffffffff813e2288
 ffffffff00000018 ffff8800519bad40 ffffed0001003821 ffff88000801c1a0
 ffff88004a277ce0 ffffffff811e9610 0000000000000296 1ffff10001003821
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff813e2288>] dump_stack+0x71/0x94 lib/dump_stack.c:51
 [<     inline     >] object_err mm/kasan/report.c:139
 [<     inline     >] print_address_description mm/kasan/report.c:180
 [<     inline     >] kasan_report_error mm/kasan/report.c:277
 [<ffffffff811e9610>] kasan_report+0x308/0x55e mm/kasan/report.c:300
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:272
 [<ffffffff811e8731>] __asan_load8+0x64/0x66 mm/kasan/kasan.c:710
 [<ffffffff811cd8d8>] unmapped_area_topdown+0x11c/0x2ee mm/mmap.c:1870
 [<     inline     >] vm_unmapped_area include/linux/mm.h:1989
 [<ffffffff8100c275>] arch_get_unmapped_area_topdown+0x243/0x278 arch/x86/kernel/sys_x86_64.c:203
 [<ffffffff8100c032>] ? arch_get_unmapped_area+0x260/0x260 arch/x86/kernel/sys_x86_64.c:161
 [<ffffffff811caedd>] get_unmapped_area+0x118/0x1dd mm/mmap.c:2047
 [<ffffffff811cf4bf>] do_mmap+0x1a3/0x542 mm/mmap.c:1330
 [<     inline     >] do_mmap_pgoff include/linux/mm.h:1941
 [<ffffffff811afc75>] vm_mmap_pgoff+0xa6/0xfc mm/util.c:297
 [<     inline     >] SYSC_mmap_pgoff mm/mmap.c:1479
 [<ffffffff811cd22c>] SyS_mmap_pgoff+0x98/0xd7 mm/mmap.c:1437
 [<     inline     >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
 [<ffffffff8100bdd0>] SyS_mmap+0x22/0x24 arch/x86/kernel/sys_x86_64.c:86
 [<ffffffff81d0b2a1>] entry_SYSCALL_64_fastpath+0x1c/0x74 arch/x86/entry/entry_64.S:199
Object at ffff88000801c0f0, in cache vm_area_struct
Object allocated with size 176 bytes.
Allocation:
PID = 18575
 [<ffffffff810175c7>] save_stack_trace+0x2b/0x46 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811e8455>] save_stack+0x46/0xce mm/kasan/kasan.c:456
 [<     inline     >] set_track mm/kasan/kasan.c:468
 [<ffffffff811e8b7d>] kasan_kmalloc+0xaf/0xbe mm/kasan/kasan.c:566
 [<ffffffff811e8f0d>] kasan_slab_alloc+0x12/0x14 mm/kasan/kasan.c:488
 [<ffffffff811e6cdb>] kmem_cache_alloc+0x87/0x106 mm/slab.c:3397
 [<     inline     >] kmem_cache_zalloc include/linux/slab.h:598
 [<     inline     >] __bprm_mm_init fs/exec.c:263
 [<     inline     >] bprm_mm_init fs/exec.c:380
 [<ffffffff81205297>] do_execveat_common.isra.37+0x536/0xbd0 fs/exec.c:1566
 [<ffffffff81205968>] do_execve+0x37/0x40 fs/exec.c:1639
 [<ffffffff8108ee86>] call_usermodehelper_exec_async+0x1b5/0x218 kernel/kmod.c:252
 [<ffffffff81d0b5ef>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:502
Memory state around the buggy address:
 ffff88000801c000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88000801c080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb fb
>ffff88000801c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff88000801c180: fb fb fb fb fc fc fc fc fc fc fc fc 00 00 00 00
 ffff88000801c200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
==================================================================
BUG: KASAN: use-after-free in vma_gap_callbacks_propagate+0xad/0x102 at addr ffff88000801c128
Read of size 8 by task crash_reporter/18575
CPU: 3 PID: 18575 Comm: crash_reporter Tainted: G    B           4.4.14 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 00000000ffffffff 00000000a1e343e8 ffff88004a277b78 ffffffff813e2288
 ffffffff00000038 ffff8800519bad40 ffffed0001003825 ffff88000801c1a0
 ffff88004a277bf0 ffffffff811e9610 0000000000000296 1ffff10001003825
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff813e2288>] dump_stack+0x71/0x94 lib/dump_stack.c:51
 [<     inline     >] object_err mm/kasan/report.c:139
 [<     inline     >] print_address_description mm/kasan/report.c:180
 [<     inline     >] kasan_report_error mm/kasan/report.c:277
 [<ffffffff811e9610>] kasan_report+0x308/0x55e mm/kasan/report.c:300
 [<ffffffff811be477>] ? anon_vma_interval_tree_remove+0x57f/0x58e mm/interval_tree.c:90
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:272
 [<ffffffff811e8731>] __asan_load8+0x64/0x66 mm/kasan/kasan.c:710
 [<     inline     >] vma_compute_subtree_gap mm/mmap.c:382
 [<ffffffff811ca4da>] vma_gap_callbacks_propagate+0xad/0x102 mm/mmap.c:493
 [<     inline     >] vma_gap_update mm/mmap.c:507
 [<ffffffff811cc132>] vma_adjust+0x5f1/0x7e1 mm/mmap.c:879
 [<     inline     >] ? is_mergeable_anon_vma mm/mmap.c:973
 [<ffffffff811cb637>] ? can_vma_merge_before+0x162/0x171 mm/mmap.c:998
 [<ffffffff811cc8da>] vma_merge+0x2e5/0x486 mm/mmap.c:1131
 [<ffffffff811ca756>] ? vm_acct_memory+0x2e/0x31 include/linux/mman.h:25
 [<ffffffff811cee07>] mmap_region+0x245/0x75a mm/mmap.c:1610
 [<ffffffff8136bb06>] ? cap_mmap_addr+0x8e/0x95 security/commoncap.c:1070
 [<ffffffff811cf7d4>] do_mmap+0x4b8/0x542 mm/mmap.c:1429
 [<     inline     >] do_mmap_pgoff include/linux/mm.h:1941
 [<ffffffff811afc75>] vm_mmap_pgoff+0xa6/0xfc mm/util.c:297
 [<     inline     >] SYSC_mmap_pgoff mm/mmap.c:1479
 [<ffffffff811cd22c>] SyS_mmap_pgoff+0x98/0xd7 mm/mmap.c:1437
 [<     inline     >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
 [<ffffffff8100bdd0>] SyS_mmap+0x22/0x24 arch/x86/kernel/sys_x86_64.c:86
 [<ffffffff81d0b2a1>] entry_SYSCALL_64_fastpath+0x1c/0x74 arch/x86/entry/entry_64.S:199
Object at ffff88000801c0f0, in cache vm_area_struct
Object allocated with size 176 bytes.
Allocation:
PID = 18575
 [<ffffffff810175c7>] save_stack_trace+0x2b/0x46 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811e8455>] save_stack+0x46/0xce mm/kasan/kasan.c:456
 [<     inline     >] set_track mm/kasan/kasan.c:468
 [<ffffffff811e8b7d>] kasan_kmalloc+0xaf/0xbe mm/kasan/kasan.c:566
 [<ffffffff811e8f0d>] kasan_slab_alloc+0x12/0x14 mm/kasan/kasan.c:488
 [<ffffffff811e6cdb>] kmem_cache_alloc+0x87/0x106 mm/slab.c:3397
 [<     inline     >] kmem_cache_zalloc include/linux/slab.h:598
 [<     inline     >] __bprm_mm_init fs/exec.c:263
 [<     inline     >] bprm_mm_init fs/exec.c:380
 [<ffffffff81205297>] do_execveat_common.isra.37+0x536/0xbd0 fs/exec.c:1566
 [<ffffffff81205968>] do_execve+0x37/0x40 fs/exec.c:1639
 [<ffffffff8108ee86>] call_usermodehelper_exec_async+0x1b5/0x218 kernel/kmod.c:252
 [<ffffffff81d0b5ef>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:502
Memory state around the buggy address:
 ffff88000801c000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88000801c080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb fb
>ffff88000801c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
 ffff88000801c180: fb fb fb fb fc fc fc fc fc fc fc fc 00 00 00 00
 ffff88000801c200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

Comment 1 by glider@chromium.org, Jul 27 2016 

There's a whole bunch of strange UAF reports from that process (see the attached syzkaller log)

Comment 2 by groeck@chromium.org, Jul 27 2016 

Does kasan detect a double free (allocated by a, freed by a, allocated by b, freed by a, used by b) ?

Comment 3 by glider@chromium.org, Jul 27 2016 

It does, but in a racy way: if two threads attempt to free the same chunk simultaneously, both of them may see it in an allocated state and attempt to put it into quarantine.
But this looks more like a real use-after-free, except for the fact there are no deallocation stacks.

Comment 4 by zalcorn@chromium.org, Dec 27 2017

Components: OS>Kernel
►

Sign in to add a comment