WARNING in kvm_arch_vcpu_ioctl_run (3)

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
99fec39e7725d091c94d1bb0242e40c8092994f6 (Fri Mar 23 22:34:18 2018 +0000)
Merge tag 'trace-v4.16-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9

Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6275011434250240
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
compiler: gcc (GCC) 7.1.1 20170620
user-space arch: i386

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+760a73...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

WARNING: CPU: 1 PID: 9515 at arch/x86/kvm/x86.c:7544
kvm_arch_vcpu_ioctl_run+0x1c7/0x5c80 arch/x86/kvm/x86.c:7544
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 9515 Comm: syz-executor4 Not tainted 4.16.0-rc6+ #274
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/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x1c7/0x5c80 arch/x86/kvm/x86.c:7544
RSP: 0018:ffff8801a2d17580 EFLAGS: 00010212
RAX: 0000000000010000 RBX: ffff8801cdfd8000 RCX: ffffffff810dfea7
RDX: 0000000000000062 RSI: ffffc90003c1b000 RDI: ffff8801ac1a8498
RBP: ffff8801a2d17910 R08: 1ffff10035835b2d R09: 0000000000000001
R10: ffff8801a2d17560 R11: 0000000000000005 R12: 0000000000000000
R13: ffff8801ab083100 R14: ffff8801ac1a8280 R15: ffff8801ac1a8280
kvm_vcpu_ioctl+0x6f1/0xff0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2560
kvm_vcpu_compat_ioctl+0x364/0x450
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2755
C_SYSC_ioctl fs/compat_ioctl.c:1461 [inline]
compat_SyS_ioctl+0x151/0x2a30 fs/compat_ioctl.c:1407
do_syscall_32_irqs_on arch/x86/entry/common.c:330 [inline]
do_fast_syscall_32+0x3ec/0xf9f arch/x86/entry/common.c:392
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f41c99
RSP: 002b:00000000f773d09c EFLAGS: 00000286 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 000000000000ae80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
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.

[Wanpeng Li]

2018-03-28 15:13 GMT+08:00 syzbot
<syzbot+760a73...@syzkaller.appspotmail.com>:

> Hello,
>
> syzbot hit the following crash on upstream commit
> 99fec39e7725d091c94d1bb0242e40c8092994f6 (Fri Mar 23 22:34:18 2018 +0000)
> Merge tag 'trace-v4.16-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6275011434250240
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
> compiler: gcc (GCC) 7.1.1 20170620
> user-space arch: i386
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+760a73...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> WARNING: CPU: 1 PID: 9515 at arch/x86/kvm/x86.c:7544

Maybe the same as this one. https://lkml.org/lkml/2018/3/21/174 Paolo,
any idea against my analysis?

Regards,
Wanpeng Li

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit: 1d2ba7fee28b Merge tag 'fbdev-v4.19-rc7' of https://github..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b019b9400000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0af03fe452b65fb
dashboard link: https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=156ad231400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+760a73...@syzkaller.appspotmail.com

kvm: emulating exchange as write
WARNING: CPU: 1 PID: 10797 at arch/x86/kvm/x86.c:7925
kvm_arch_vcpu_ioctl_run+0x1ca/0x16e0 arch/x86/kvm/x86.c:7925

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 10797 Comm: syz-executor4 Not tainted 4.19.0-rc6+ #264

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:

__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x1ca/0x16e0 arch/x86/kvm/x86.c:7925
Code: 03 80 3c 02 00 0f 85 f0 13 00 00 4c 8b a3 18 2c 00 00 31 ff 4c 89 e6
e8 74 96 6e 00 4d 85 e4 0f 84 fd 0a 00 00 e8 36 95 6e 00 <0f> 0b e8 2f 95
6e 00 49 8d 7d 01 48 b8 00 00 00 00 00 fc ff df 48
RSP: 0018:ffff8801d7fff860 EFLAGS: 00010293
RAX: ffff8801c92de280 RBX: ffff8801c8fe0540 RCX: ffffffff81102b80
RDX: 0000000000000000 RSI: ffffffff8110204a RDI: 0000000000000005
RBP: ffff8801d7fff8d8 R08: ffff8801c92de280 R09: 1ffffffff1273955
R10: ffffed003b5e4732 R11: ffff8801daf23993 R12: 0000000000000001
R13: ffff8801c29a7000 R14: 0000000000000000 R15: ffff8801c8fe0618
kvm_vcpu_ioctl+0x72b/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2590
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f51c3ee0c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f51c3ee16d4
R13: 00000000004c003b R14: 00000000004d0108 R15: 00000000ffffffff

[syzbot]

syzbot has bisected this bug to:

commit 706249c222f68471b6f8e9e8e9b77665c404b226
Author: Peter Zijlstra <pet...@infradead.org>
Date: Fri Jul 24 13:06:37 2015 +0000

locking/static_keys: Rework update logic

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=175cc587200000
start commit: 1d2ba7fe Merge tag 'fbdev-v4.19-rc7' of https://github.com..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=14dcc587200000
console output: https://syzkaller.appspot.com/x/log.txt?x=10dcc587200000

kernel config: https://syzkaller.appspot.com/x/.config?x=c0af03fe452b65fb
dashboard link: https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=156ad231400000

Reported-by: syzbot+760a73...@syzkaller.appspotmail.com
Fixes: 706249c222f6 ("locking/static_keys: Rework update logic")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit: 963172d9 Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11422276a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=fa9f7e1b6a8bb586
dashboard link: https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=103d3e21a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1645f956a00000

The bug was bisected to:

commit 706249c222f68471b6f8e9e8e9b77665c404b226
Author: Peter Zijlstra <pet...@infradead.org>
Date: Fri Jul 24 13:06:37 2015 +0000

locking/static_keys: Rework update logic

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=175cc587200000

final crash: https://syzkaller.appspot.com/x/report.txt?x=14dcc587200000
console output: https://syzkaller.appspot.com/x/log.txt?x=10dcc587200000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+760a73...@syzkaller.appspotmail.com

Fixes: 706249c222f6 ("locking/static_keys: Rework update logic")

WARNING: CPU: 1 PID: 9153 at arch/x86/kvm/x86.c:8302
kvm_arch_vcpu_ioctl_run+0x1d8/0x1740 arch/x86/kvm/x86.c:8302

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 9153 Comm: syz-executor142 Not tainted 5.2.0-rc4+ #53

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:

__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x744 kernel/panic.c:219
__warn.cold+0x20/0x4d kernel/panic.c:576
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x1d8/0x1740 arch/x86/kvm/x86.c:8302
Code: 80 3c 02 00 0f 85 09 14 00 00 49 8b 9c 24 18 0d 00 00 31 ff 48 89 de
e8 56 93 62 00 48 85 db 0f 84 77 0c 00 00 e8 a8 91 62 00 <0f> 0b e8 a1 91
62 00 49 8d 7e 01 48 b8 00 00 00 00 00 fc ff df 48
RSP: 0018:ffff8880a0a6fb30 EFLAGS: 00010293
RAX: ffff8880863945c0 RBX: 0000000000000001 RCX: ffffffff810e3c69
RDX: 0000000000000000 RSI: ffffffff810e2fb8 RDI: 0000000000000005
RBP: ffff8880a0a6fb98 R08: ffff8880863945c0 R09: ffffed1015d26be0
R10: ffffed1015d26bdf R11: ffff8880ae935efb R12: ffff8880a4048040
R13: 0000000000000000 R14: ffff8880937c8000 R15: ffff8880a38d2680
kvm_vcpu_ioctl+0x4dc/0xf90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2755
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x448cb9
Code: e8 8c b0 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7

48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff

ff 0f 83 4b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff6ad8dcce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006ddc58 RCX: 0000000000448cb9

RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005

RBP: 00000000006ddc50 R08: 00007ff6ad8dd700 R09: 0000000000000000
R10: 00007ff6ad8dd700 R11: 0000000000000246 R12: 00000000006ddc5c
R13: 00007ffdd645a21f R14: 00007ff6ad8dd9c0 R15: 20c49ba5e353f7cf

[Tetsuo Handa]

On 2018/03/28 16:29, Wanpeng Li wrote:
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
>>

> Maybe the same as this one. https://lkml.org/lkml/2018/3/21/174 Paolo,
> any idea against my analysis?

No progress for 4 years. Did somebody check Wanpeng's analysis ?

Since I'm not familiar with KVM, my questions from different direction...



syzbot is hitting WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed) added by
commit 716d51abff06f484 ("KVM: Provide userspace IO exit completion callback")
due to vcpu->mmio_needed == true.

Question 1: what is the intent of checking for vcpu->mmio_needed == false?



If we run a reproducer provided by syzbot, we can observe that mutex_unlock(&vcpu->mutex)
in kvm_vcpu_ioctl() is called with vcpu->mmio_needed == true.

Question 2: Is kvm_vcpu_ioctl() supposed to leave with vcpu->mmio_needed == false?
In other words, is doing

--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4104,6 +4104,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
r = kvm_arch_vcpu_ioctl(filp, ioctl, arg);
}
out:
+ WARN_ON_ONCE(vcpu->mmio_needed);
mutex_unlock(&vcpu->mutex);
kfree(fpu);
kfree(kvm_sregs);

appropriate?

[Sean Christopherson]

On Wed, Jun 22, 2022, Tetsuo Handa wrote:
> On 2018/03/28 16:29, Wanpeng Li wrote:
> >> syzbot dashboard link:
> >> https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
> >>
> > Maybe the same as this one. https://lkml.org/lkml/2018/3/21/174 Paolo,
> > any idea against my analysis?
>
> No progress for 4 years. Did somebody check Wanpeng's analysis ?

The most recent failure is a different bug, the splat Wanpeng debugged requires
unrestricted guest to be disabled, whereas this does not. Somewhat of a side
topic, if the old bug still exists (the syzkaller reproducer fails with invalid
guest state, so it's not clear whether or not the bug is still a problem),
I suspect this hack-a-fix would handle the Real Mode injection case:

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 735543df829a..58801d3888c8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8209,7 +8209,7 @@ void kvm_inject_realmode_interrupt(struct kvm_vcpu *vcpu, int irq, int inc_eip)
ctxt->_eip = ctxt->eip + inc_eip;
ret = emulate_int_real(ctxt, irq);

- if (ret != X86EMUL_CONTINUE) {
+ if (ret != X86EMUL_CONTINUE || vcpu->mmio_needed) {
kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
} else {
ctxt->eip = ctxt->_eip;

If I ever have time and/or get bored, I'll try to repro the realmode bug unless
someone beats me to it.

> Since I'm not familiar with KVM, my questions from different direction...
>
>
>
> syzbot is hitting WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed) added by
> commit 716d51abff06f484 ("KVM: Provide userspace IO exit completion callback")
> due to vcpu->mmio_needed == true.
>
> Question 1: what is the intent of checking for vcpu->mmio_needed == false?

It's a sanity check to detect KVM bugs. If vcpu->mmio_needed is true, KVM needs
to exit to userspace to complete the MMIO operation. On that exit to userspace,
KVM is supposed to also set a callback to essentially acknowledge that the MMIO
completed.

The issue in this bug is that after setting vcpu->mmio_needed, KVM detects and
injects an exception. Because of how KVM handles MMIO, unlike MMIO reads, MMIO
writes don't immediately stop emulation. While odd, it should work because MMIO
writes shouldn't be processed until after all fault checks have passed. The
underlying bug is that LTR emulation has incorrect ordering and checks for a
non-canonical base _after_ marking the TSS as busy (which triggers MMIO).

So as much as I want to suppress this type of warn by clearing vcpu->mmio_needed
when injecting an exception, I suspect playing whack-a-mole is the right approach
because all those moles are likely bugs :-( Though one thing we can do is change
the WARN_ON() to a WARN_ON_ONCE() so that kernels outside of panic_on_warn=1 won't
blow up on a buggy/malicious userspace.

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 39ea9138224c..09e4b67b881f 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1699,16 +1699,6 @@ static int __load_segment_descriptor(struct x86_emulate_ctxt *ctxt,
case VCPU_SREG_TR:
if (seg_desc.s || (seg_desc.type != 1 && seg_desc.type != 9))
goto exception;
- if (!seg_desc.p) {
- err_vec = NP_VECTOR;
- goto exception;
- }
- old_desc = seg_desc;
- seg_desc.type |= 2; /* busy */
- ret = ctxt->ops->cmpxchg_emulated(ctxt, desc_addr, &old_desc, &seg_desc,
- sizeof(seg_desc), &ctxt->exception);
- if (ret != X86EMUL_CONTINUE)
- return ret;
break;
case VCPU_SREG_LDTR:
if (seg_desc.s || seg_desc.type != 2)
@@ -1749,6 +1739,15 @@ static int __load_segment_descriptor(struct x86_emulate_ctxt *ctxt,
((u64)base3 << 32), ctxt))
return emulate_gp(ctxt, 0);
}
+
+ if (seg == VCPU_SREG_TR) {
+ old_desc = seg_desc;
+ seg_desc.type |= 2; /* busy */
+ ret = ctxt->ops->cmpxchg_emulated(ctxt, desc_addr, &old_desc, &seg_desc,
+ sizeof(seg_desc), &ctxt->exception);
+ if (ret != X86EMUL_CONTINUE)
+ return ret;
+ }
load:
ctxt->ops->set_segment(ctxt, selector, &seg_desc, base3, seg);
if (desc)

> If we run a reproducer provided by syzbot, we can observe that mutex_unlock(&vcpu->mutex)
> in kvm_vcpu_ioctl() is called with vcpu->mmio_needed == true.
>
> Question 2: Is kvm_vcpu_ioctl() supposed to leave with vcpu->mmio_needed == false?
> In other words, is doing
>
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4104,6 +4104,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> r = kvm_arch_vcpu_ioctl(filp, ioctl, arg);
> }
> out:
> + WARN_ON_ONCE(vcpu->mmio_needed);
> mutex_unlock(&vcpu->mutex);
> kfree(fpu);
> kfree(kvm_sregs);
>
> appropriate?

It's not appropriate, mmio_needed is actually supposed to be accompanied by a
exit from kvm_vcpu_ioctl() to userspace.