'WARNING in handle_exception_nmi' bug at arch/x86/kvm/vmx/vmx.c:4959

[潘高宁]

Hello,

    This is Xiao Lei, Gaoning Pan and Yongkang Jia from Zhejiang University. We found a 'WARNING in handle_exception_nmi' bug by syzkaller. This flaw allows a malicious user in a local DoS condition. The following program triggers Local DoS at arch/x86/kvm/vmx/vmx.c:4959 in latest release linux-5.18.5, this bug can be reproducible stably by the C reproducer:

------------[ cut here ]------------
WARNING: CPU: 14 PID: 9277 at arch/x86/kvm/vmx/vmx.c:4959 handle_exception_nmi+0x11a7/0x14d0 arch/x86/kvm/vmx/vmx.c:4959
Modules linked in:
CPU: 14 PID: 9277 Comm: syz-executor.7 Not tainted 5.18.5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:handle_exception_nmi+0x11a7/0x14d0 arch/x86/kvm/vmx/vmx.c:4959
Code: ff e8 1d b7 3c 00 be 0c 44 00 00 48 c7 c7 00 c9 23 8a c6 05 9f 71 5e 04 01 e8 5b 02 8d 02 0f 0b e9 64 f8 ff ff e8 f9 b6 3c 00 <0f> 0b e9 ae f4 ff ff e8 ed b6 3c 00 e8 28 97 a0 02 e9 5f fd ff ff
RSP: 0018:ffff888038dc7b48 EFLAGS: 00010286
RAX: 0000000000002617 RBX: 0000000000000000 RCX: ffffffff811dcf27
RDX: 0000000000040000 RSI: ffffc90003dd1000 RDI: ffff888039595c0c
RBP: ffff888039594000 R08: 0000000000000001 R09: ffff8880395941a7
R10: ffffed10072b2834 R11: 0000000000000001 R12: fffffffffffffff8
R13: 000000008000030e R14: ffff88803895c000 R15: ffff888039594068
FS:  00007ff56edf7700(0000) GS:ffff888067d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000003aec8006 CR4: 0000000000772ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <TASK>
 __vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6239 [inline]
 vmx_handle_exit+0x5e7/0x1aa0 arch/x86/kvm/vmx/vmx.c:6256
 vcpu_enter_guest arch/x86/kvm/x86.c:10283 [inline]
 vcpu_run arch/x86/kvm/x86.c:10365 [inline]
 kvm_arch_vcpu_ioctl_run+0x2a2e/0x5ca0 arch/x86/kvm/x86.c:10566
 kvm_vcpu_ioctl+0x4d2/0xc60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3943
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x16d/0x1d0 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x45e8c9
Code: 4d af 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 1b af fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff56edf6c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000000077bf60 RCX: 000000000045e8c9
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
RBP: 000000000077bf60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc491be6af R14: 00007ff56edf79c0 R15: 0000000000000000
 </TASK>
---[ end trace 0000000000000000 ]---

Syzkaller reproducer:
# {Threaded:false Repeat:false RepeatTimes:0 Procs:1 Slowdown:1 Sandbox: Leak:false NetInjection:false NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false VhciInjection:false Wifi:false IEEE802154:false Sysctl:true UseTmpDir:false HandleSegv:false Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}}
r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x0, 0x0)
r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
r2 = ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0)
syz_kvm_setup_cpu$x86(r1, r2, &(0x7f0000fe8000/0x18000)=nil, &(0x7f00000000c0)=[@textreal={0x8, 0x0}], 0x1, 0x17, &(0x7f0000000100)=[@cr4={0x1, 0x200915}], 0x1)
ioctl$KVM_RUN(r2, 0xae80, 0x0)

C repro and config are attached.

Best regrads.

Xiao Lei from Zhejiang University.

[Dmitry Vyukov]

On Mon, 20 Jun 2022 at 12:25, 潘高宁 <p...@zju.edu.cn> wrote:
>
> Hello,
>
> This is Xiao Lei, Gaoning Pan and Yongkang Jia from Zhejiang University. We found a 'WARNING in handle_exception_nmi' bug by syzkaller. This flaw allows a malicious user in a local DoS condition. The following program triggers Local DoS at arch/x86/kvm/vmx/vmx.c:4959 in latest release linux-5.18.5, this bug can be reproducible stably by the C reproducer:

FWIW a similarly-looking issue was reported by syzbot:
https://syzkaller.appspot.com/bug?id=1b411bfb1739c497a8f0c7f1aa501202726cd01a
https://lore.kernel.org/all/0000000000000a...@google.com/

Sean said it may be an issue in L0 kernel rather than in the tested kernel:
https://lore.kernel.org/all/Yqd5upAH...@google.com/

What kernel did you use for the host machine?

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/69ab985c.7d507.18180a4dcd7.Coremail.pgn%40zju.edu.cn.

[Red Hat Product Security]

Hello!

INC2255898 (Re: 'WARNING in handle_exception_nmi' bug at arch/x86/kvm/vmx/vmx.c:4959) has been updated.

Opened for: dvy...@google.com
Followers: p...@zju.edu.cn, kan...@zju.edu.cn, x...@kernel.org, wanp...@tencent.com, k...@vger.kernel.org, sea...@google.com, jo...@8bytes.org, dave....@linux.intel.com, linux-...@vger.kernel.org, 2212...@zju.edu.cn, Ingo Molnar, b...@alien8.de, syzk...@googlegroups.com, h...@zytor.com, Paolo Bonzini, Vitaly Kuznetsov, jmat...@google.com, tg...@linutronix.de, linu...@vger.kernel.org

Paolo Bonzini updated your request with the following comments:

Reply from: pbon...@redhat.com

 

View email thread

On 6/20/22 13:24, Dmitry Vyukov wrote:
> On Mon, 20 Jun 2022 at 12:25, 潘高宁 <p...@zju.edu.cn> wrote:
>>
>> Hello,
>>
>> This is Xiao Lei, Gaoning Pan and Yongkang Jia from Zhejiang University. We found a 'WARNING in handle_exception_nmi' bug by syzkaller. This flaw allows a malicious user in a local DoS condition. The following program triggers Local DoS at arch/x86/kvm/vmx/vmx.c:4959 in latest release linux-5.18.5, this bug can be reproducible stably by the C reproducer:
>
>
> FWIW a similarly-looking issue was reported by syzbot:
> https://syzkaller.appspot.com/bug?id=1b411bfb1739c497a8f0c7f1aa501202726cd01a
> https://lore.kernel.org/all/0000000000000a...@google.com/
>
> Sean said it may be an issue in L0 kernel rather than in the tested kernel:
> https://lore.kernel.org/all/Yqd5upAH...@google.com/

Indeed I cannot reproduce these either on bare metal.

Paolo

How can I track and update my request?

To respond, reply to this email. You may also create a new email and include the request number (INC2255898) in the subject.

Thank you,
Product Security

 

Ref:MSG60002758

[潘高宁]

Our host machine is linux-5.11.0.

> -----原始邮件-----
> 发件人: "Dmitry Vyukov" <dvy...@google.com>
> 发送时间: 2022-06-20 19:24:26 (星期一)
> 收件人: "潘高宁" <p...@zju.edu.cn>
> 抄送: linu...@vger.kernel.org, seca...@redhat.com, pbon...@redhat.com, sea...@google.com, vkuz...@redhat.com, wanp...@tencent.com, jmat...@google.com, jo...@8bytes.org, tg...@linutronix.de, mi...@redhat.com, b...@alien8.de, dave....@linux.intel.com, x...@kernel.org, h...@zytor.com, k...@vger.kernel.org, linux-...@vger.kernel.org, syzk...@googlegroups.com, kan...@zju.edu.cn, 2212...@zju.edu.cn
> 主题: Re: 'WARNING in handle_exception_nmi' bug at arch/x86/kvm/vmx/vmx.c:4959

[Paolo Bonzini]

On 6/20/22 13:24, Dmitry Vyukov wrote:

> On Mon, 20 Jun 2022 at 12:25, 潘高宁 <p...@zju.edu.cn> wrote:
>>
>> Hello,
>>
>> This is Xiao Lei, Gaoning Pan and Yongkang Jia from Zhejiang University. We found a 'WARNING in handle_exception_nmi' bug by syzkaller. This flaw allows a malicious user in a local DoS condition. The following program triggers Local DoS at arch/x86/kvm/vmx/vmx.c:4959 in latest release linux-5.18.5, this bug can be reproducible stably by the C reproducer:
>
>
> FWIW a similarly-looking issue was reported by syzbot:
> https://syzkaller.appspot.com/bug?id=1b411bfb1739c497a8f0c7f1aa501202726cd01a
> https://lore.kernel.org/all/0000000000000a...@google.com/
>
> Sean said it may be an issue in L0 kernel rather than in the tested kernel:
> https://lore.kernel.org/all/Yqd5upAH...@google.com/