KASAN: use-after-free Read in __schedule

70 views
Skip to first unread message

syzbot

unread,
Dec 20, 2017, 11:03:04 AM12/20/17
to h...@zytor.com, k...@vger.kernel.org, linux-...@vger.kernel.org, mi...@redhat.com, pbon...@redhat.com, rkr...@redhat.com, syzkall...@googlegroups.com, tg...@linutronix.de, x...@kernel.org
Hello,

syzkaller hit the following crash on
7dc9f647127d6955ffacaf51cb6a627b31dceec2
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
==================================================================
BUG: KASAN: use-after-free in __fire_sched_out_preempt_notifiers
kernel/sched/core.c:2550 [inline]
BUG: KASAN: use-after-free in fire_sched_out_preempt_notifiers
kernel/sched/core.c:2558 [inline]
BUG: KASAN: use-after-free in prepare_task_switch kernel/sched/core.c:2594
[inline]
BUG: KASAN: use-after-free in context_switch kernel/sched/core.c:2765
[inline]
BUG: KASAN: use-after-free in __schedule+0xda3/0x2060
kernel/sched/core.c:3376
Read of size 8 at addr ffff8801c8cb8058 by task syzkaller738410/3153

CPU: 1 PID: 3153 Comm: syzkaller738410 Not tainted
4.15.0-rc4-next-20171220+ #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
__fire_sched_out_preempt_notifiers kernel/sched/core.c:2550 [inline]
fire_sched_out_preempt_notifiers kernel/sched/core.c:2558 [inline]
prepare_task_switch kernel/sched/core.c:2594 [inline]
context_switch kernel/sched/core.c:2765 [inline]
__schedule+0xda3/0x2060 kernel/sched/core.c:3376
preempt_schedule_common+0x22/0x60 kernel/sched/core.c:3515
_cond_resched+0x1d/0x30 kernel/sched/core.c:4852
__wait_for_common kernel/sched/completion.c:107 [inline]
wait_for_common kernel/sched/completion.c:123 [inline]
wait_for_completion+0xa5/0x770 kernel/sched/completion.c:144
__synchronize_srcu+0x1ad/0x260 kernel/rcu/srcutree.c:925
synchronize_srcu_expedited kernel/rcu/srcutree.c:950 [inline]
synchronize_srcu+0x1a3/0x570 kernel/rcu/srcutree.c:1001
kvm_page_track_unregister_notifier+0x186/0x270
arch/x86/kvm/page_track.c:213
kvm_mmu_uninit_vm+0x1c/0x20 arch/x86/kvm/mmu.c:5053
kvm_arch_destroy_vm+0x73b/0x980 arch/x86/kvm/x86.c:8418
kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:728 [inline]
kvm_put_kvm+0x695/0xde0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:749
kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:760
__fput+0x327/0x7e0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x199/0x270 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x9bb/0x1ad0 kernel/exit.c:869
do_group_exit+0x149/0x400 kernel/exit.c:972
SYSC_exit_group kernel/exit.c:983 [inline]
SyS_exit_group+0x1d/0x20 kernel/exit.c:981
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x43ee18
RSP: 002b:00007ffcbff2d938 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 000000000043ee18
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00000000006ca018 R08: 00000000000000e7 R09: ffffffffffffffd0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401b40
R13: 0000000000401bd0 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 3153:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3545
kmem_cache_zalloc include/linux/slab.h:695 [inline]
vmx_create_vcpu+0xc4/0x2f20 arch/x86/kvm/vmx.c:9819
kvm_arch_vcpu_create+0x12c/0x1a0 arch/x86/kvm/x86.c:7884
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:2445
[inline]
kvm_vm_ioctl+0x48b/0x1c60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2943
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
entry_SYSCALL_64_fastpath+0x1f/0x96

Freed by task 3153:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
__cache_free mm/slab.c:3489 [inline]
kmem_cache_free+0x83/0x2a0 mm/slab.c:3747
vmx_free_vcpu+0x1ee/0x260 arch/x86/kvm/vmx.c:9813
kvm_arch_vcpu_free arch/x86/kvm/x86.c:7870 [inline]
kvm_free_vcpus arch/x86/kvm/x86.c:8317 [inline]
kvm_arch_destroy_vm+0x4a2/0x980 arch/x86/kvm/x86.c:8416
kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:728 [inline]
kvm_put_kvm+0x695/0xde0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:749
kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:760
__fput+0x327/0x7e0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x199/0x270 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x9bb/0x1ad0 kernel/exit.c:869
do_group_exit+0x149/0x400 kernel/exit.c:972
SYSC_exit_group kernel/exit.c:983 [inline]
SyS_exit_group+0x1d/0x20 kernel/exit.c:981
entry_SYSCALL_64_fastpath+0x1f/0x96

The buggy address belongs to the object at ffff8801c8cb8040
which belongs to the cache kvm_vcpu of size 23872
The buggy address is located 24 bytes inside of
23872-byte region [ffff8801c8cb8040, ffff8801c8cbdd80)
The buggy address belongs to the page:
page:00000000cd7a3442 count:1 mapcount:0 mapping:00000000f1888586 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801c8cb8040 0000000000000000 0000000100000001
raw: ffff8801d6426748 ffff8801d6426748 ffff8801d6430c00 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8801c8cb7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801c8cb7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801c8cb8000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801c8cb8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c8cb8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is merged into any tree, reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
config.txt
raw.log
repro.txt
repro.c

Eric Biggers

unread,
Dec 20, 2017, 7:25:25 PM12/20/17
to k...@vger.kernel.org, pbon...@redhat.com, rkr...@redhat.com, tiany...@intel.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers
From: Eric Biggers <ebig...@google.com>

Due to a bad merge resolution between commit f29810335965 ("KVM/x86:
Check input paging mode when cs.l is set") and commit b4ef9d4e8cb8
("KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs"),
there is a case in kvm_arch_vcpu_ioctl_set_sregs() where vcpu_put() is
not called after vcpu_get(). Fix it.

Reported-by: syzbot <syzk...@googlegroups.com>
Signed-off-by: Eric Biggers <ebig...@google.com>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ea3a98196753..f4e8b5089b28 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7624,7 +7624,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
goto out;

if (kvm_valid_sregs(vcpu, sregs))
- return -EINVAL;
+ goto out;

apic_base_msr.data = sregs->apic_base;
apic_base_msr.host_initiated = true;
--
2.15.1.620.gb9897f4670-goog

Paolo Bonzini

unread,
Dec 20, 2017, 7:30:37 PM12/20/17
to Eric Biggers, k...@vger.kernel.org, rkr...@redhat.com, tiany...@intel.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers, Stephen Rothwell, Linux-Next Mailing List
Thanks very much Eric, that was fast! Adding Stephen and the linux-next
mailing list to Cc. Adding the kvm/master tree has already paid off.

Paolo

Stephen Rothwell

unread,
Dec 20, 2017, 8:02:32 PM12/20/17
to Paolo Bonzini, Eric Biggers, k...@vger.kernel.org, rkr...@redhat.com, tiany...@intel.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers, Linux-Next Mailing List
Hi Paolo,
I will apply that as a merge fix patch for the kvm tree merge from
today. Please remember to apply it if/when you merge the master branch
into your linux-next branch or when these trees meet in Linus' tree.
--
Cheers,
Stephen Rothwell

Lan Tianyu

unread,
Dec 20, 2017, 8:44:14 PM12/20/17
to Eric Biggers, k...@vger.kernel.org, pbon...@redhat.com, rkr...@redhat.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers
Hi Eric:
Nice catch. Thanks to fix it.

Lan Tianyu

unread,
Dec 20, 2017, 9:56:26 PM12/20/17
to Paolo Bonzini, Eric Biggers, k...@vger.kernel.org, rkr...@redhat.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers, Stephen Rothwell, Linux-Next Mailing List
Hi Paolo:
Should we check input sregs before loading vcpu? If input sregs is
invalid, the operation is redundant.
--
Best regards
Tianyu Lan

Paolo Bonzini

unread,
Dec 21, 2017, 4:07:50 AM12/21/17
to Lan Tianyu, Eric Biggers, k...@vger.kernel.org, rkr...@redhat.com, christof...@linaro.org, x...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Eric Biggers, Stephen Rothwell, Linux-Next Mailing List
On 21/12/2017 03:45, Lan Tianyu wrote:
> Hi Paolo:
> Should we check input sregs before loading vcpu? If input sregs is
> invalid, the operation is redundant.

That would be another way to fix the conflict. Note that the conflict
is between two different trees (kvm/master and kvm/next), so in any case
it will remain until the next merge window.

Paolo

Eric Biggers

unread,
Feb 13, 2018, 2:28:41 PM2/13/18
to syzbot, syzkall...@googlegroups.com
This was fixed by commit 8dbfb2bf1bb38:

#syz fix: KVM: x86: don't forget vcpu_put() in kvm_arch_vcpu_ioctl_set_sregs()

- Eric
Reply all
Reply to author
Forward
0 new messages