The following bug has been found with syzkaller (no repro so far) on the 3.18 amd64-generic kernel:

==================================================================
BUG: KASAN: use-after-free in free_vmap_area_noflush+0x3e/0xdd at addr ffff88002fbbd608
Read of size 8 by task syz-executor/14508
CPU: 3 PID: 14508 Comm: syz-executor Tainted: G    B   W      3.18.0 #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffff88002fbbd680 0000000090fcb8ea ffff880026d278d8 ffffffff81b5b07c
 00000000000038ac ffffffffffff0006 ffff880051800000 ffffed0005f77ac1
 ffff880026d27958 ffffffff811c85c4 0000000000000296 1ffff10005f77ac1
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff81b5b07c>] dump_stack+0x74/0xb3 lib/dump_stack.c:50
 [<     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
 [<ffffffff811c85c4>] kasan_report+0x30f/0x565 mm/kasan/report.c:300
 [<ffffffff811b6c2b>] ? free_vmap_area_noflush+0x30/0xdd mm/vmalloc.c:677
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:292
 [<ffffffff811c74b5>] __asan_load8+0x64/0x66 mm/kasan/kasan.c:730
 [<ffffffff811b6c39>] free_vmap_area_noflush+0x3e/0xdd mm/vmalloc.c:678
 [<     inline     >] free_unmap_vmap_area_noflush mm/vmalloc.c:690
 [<     inline     >] free_unmap_vmap_area mm/vmalloc.c:699
 [<ffffffff811b8999>] remove_vm_area+0xd9/0xfd mm/vmalloc.c:1423
 [<ffffffff811b8a0e>] __vunmap+0x51/0x14c mm/vmalloc.c:1442
 [<ffffffff811b8c08>] vfree+0xa9/0xb3 mm/vmalloc.c:1499
 [<ffffffff8124195f>] elf_core_dump+0x1aad/0x1d1d fs/binfmt_elf.c:2026
 [<ffffffff8124df1c>] do_coredump+0xf0d/0x1389 fs/coredump.c:674
 [<ffffffff8107297e>] ? __sigqueue_free+0x5e/0x62 kernel/signal.c:398
 [<ffffffff81078bbc>] get_signal+0x8e2/0x950 kernel/signal.c:2344
 [<ffffffff8100320b>] do_signal+0x37/0x8a4 arch/x86/kernel/signal.c:703
 [<     inline     >] ? fatal_signal_pending include/linux/sched.h:2792
 [<ffffffff8105292f>] ? __do_page_fault+0x4a5/0x5de arch/x86/mm/fault.c:1246
 [<ffffffff8109860a>] ? task_rq_unlock+0x2a/0x2f kernel/sched/core.c:366
 [<ffffffff810e7c5b>] ? timekeeping_get_ns+0x82/0x93 kernel/time/timekeeping.c:206
 [<ffffffff81003aa4>] do_notify_resume+0x2c/0x6d arch/x86/kernel/signal.c:754
 [<ffffffff81052ab8>] ? do_page_fault+0x25/0x27 arch/x86/mm/fault.c:1299
 [<ffffffff81b638f7>] retint_signal+0x41/0x7a arch/x86/kernel/entry_64.S:925
Object at ffff88002fbbd600, in cache kmalloc-128
Object freed, allocated with size 104 bytes
Allocation:
PID = 14508
 [<ffffffff810159f0>] save_stack_trace+0x2c/0x48 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811c73c9>] save_stack+0x46/0xce mm/kasan/kasan.c:476
 [<     inline     >] set_track mm/kasan/kasan.c:488
 [<ffffffff811c7b40>] kasan_kmalloc+0xae/0xc0 mm/kasan/kasan.c:586
 [<ffffffff811c5d84>] kmem_cache_alloc_trace+0x93/0xc6 mm/slab.c:3409
 [<     inline     >] kmem_cache_alloc_node_trace include/linux/slab.h:328
 [<     inline     >] kmalloc_node include/linux/slab.h:475
 [<ffffffff811b702b>] alloc_vmap_area.isra.23+0xb0/0x479 mm/vmalloc.c:359
 [<ffffffff811b74f3>] __get_vm_area_node.isra.24+0xff/0x1c8 mm/vmalloc.c:1331
 [<ffffffff811b8eb4>] __vmalloc_node_range+0x8f/0x35b mm/vmalloc.c:1645
 [<ffffffff811b91e0>] __vmalloc_node+0x60/0x69 mm/vmalloc.c:1694
 [<     inline     >] __vmalloc_node_flags mm/vmalloc.c:1708
 [<ffffffff811b9409>] vmalloc+0x3b/0x3d mm/vmalloc.c:1723
 [<     inline     >] fill_note_info fs/binfmt_elf.c:1670
 [<ffffffff81240f28>] elf_core_dump+0x1076/0x1d1d fs/binfmt_elf.c:2077
 [<ffffffff8124df1c>] do_coredump+0xf0d/0x1389 fs/coredump.c:674
 [<ffffffff81078bbc>] get_signal+0x8e2/0x950 kernel/signal.c:2344
 [<ffffffff8100320b>] do_signal+0x37/0x8a4 arch/x86/kernel/signal.c:703
 [<ffffffff81003aa4>] do_notify_resume+0x2c/0x6d arch/x86/kernel/signal.c:754
 [<ffffffff81b638f7>] retint_signal+0x41/0x7a arch/x86/kernel/entry_64.S:925
Deallocation:
PID = 0
 [<ffffffff810159f0>] save_stack_trace+0x2c/0x48 arch/x86/kernel/stacktrace.c:64
 [<ffffffff811c73c9>] save_stack+0x46/0xce mm/kasan/kasan.c:476
 [<     inline     >] set_track mm/kasan/kasan.c:488
 [<ffffffff811c7fa1>] kasan_slab_free+0x94/0xca mm/kasan/kasan.c:540
 [<     inline     >] __cache_free mm/slab.c:3344
 [<ffffffff811c6105>] kfree+0x4c/0x95 mm/slab.c:3576
 [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:113
 [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2332
 [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:2592
 [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:2559
 [<ffffffff810d689c>] rcu_process_callbacks+0x3a6/0x6c1 kernel/rcu/tree.c:2576
 [<ffffffff81b655b5>] __do_softirq+0x125/0x33b kernel/softirq.c:270
Memory state around the buggy address:
 ffff88002fbbd500: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 ffff88002fbbd580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff88002fbbd600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff88002fbbd680: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 ffff88002fbbd700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================

Looks like this has been reported previously by Sasha Levin (https://lkml.org/lkml/2016/4/17/44), not sure it was fixed though.