All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: 'WARNING in vcpu_enter_guest' bug in arch/x86/kvm/x86.c:9877
       [not found] <ca5aa7c.e8ca9.17f71bde91a.Coremail.pgn@zju.edu.cn>
@ 2022-04-15 21:09 ` Sean Christopherson
  0 siblings, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2022-04-15 21:09 UTC (permalink / raw)
  To: 潘高宁
  Cc: pbonzini, vkuznets, wanpengli, jmattson, joro, tglx, mingo, bp,
	dave.hansen, hpa, jarkko, kvm, linux-kernel, linux-sgx, secalert,
	syzkaller, kangel

On Thu, Mar 10, 2022, 潘高宁 wrote:
> Hello, This is Gaoning Pan and Yongkang Jia from Zhejiang University. We
> found a 'WARNING in vcpu_enter_guest' bug by syzkaller. This flaw allows a
> malicious user in a Local DOS condition. The following program triggers Local
> DOS in vcpu_enter_guest in arch/x86/kvm/x86.c:9877 in latest release
> linux-5.16.13, this bug can be reproducible stably by the C reproducer:
> 
> ------------[ cut here ]------------

...

> Syzkaller reproducer:
> # {Threaded:true Repeat:true RepeatTimes:0 Procs:16 Slowdown:1 Sandbox:
> r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x0, 0x0)
> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> ioctl$KVM_CAP_SPLIT_IRQCHIP(r1, 0x4068aea3, &(0x7f0000000000)) (async)
> r2 = ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0) (async)
> r3 = ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x400000000000002)
> ioctl$KVM_SET_GUEST_DEBUG(r3, 0x4048ae9b, &(0x7f00000000c0)={0x5dda9c14aa95f5c5})
> ioctl$KVM_RUN(r2, 0xae80, 0x0)
> 
> C repro and kernel config are attached.

Reproduced, should have a fix posted shortly, thanks!

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 'WARNING in vcpu_enter_guest' bug in arch/x86/kvm/x86.c:9877
       [not found] <25270242.531.1655475119097@app133160.ycg3.service-now.com>
@ 2022-06-17 16:28 ` Sean Christopherson
  0 siblings, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2022-06-17 16:28 UTC (permalink / raw)
  To: Red Hat Product Security
  Cc: mingo, bp, pgn, pbonzini, wanpengli, kvm, linux-kernel, tglx,
	kangel, syzkaller, jmattson, vkuznets, dave.hansen, linux-sgx,
	jarkko, joro, hpa

On Fri, Jun 17, 2022, Red Hat Product Security wrote:
> Hello!
> 
> INC2131147 ('WARNING in vcpu_enter_guest' bug in arch/x86/kvm/x86.c:9877) is pending your review.
> 
> Opened for: pgn@zju.edu.cn
> Followers: Paolo Bonzini, seanjc@google.com, Vitaly Kuznetsov, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, tglx@linutronix.de, Ingo Molnar, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, jarkko@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org, kangel@zju.edu.cn, syzkaller@googlegroups.com
> 
> Mauro Matteo Cascella updated your request with the following comments:
> 
> Hi Sean,
>  Thanks for the fix: https://github.com/torvalds/linux/commit/423ecfea77dda83823c71b0fad1c2ddb2af1e5fc [https://github.com/torvalds/linux/commit/423ecfea77dda83823c71b0fad1c2ddb2af1e5fc].
> Is this CVE worthy? As /dev/kvm is world accessible and unprivileged users could trigger the bug IIUC. We (Red Hat) can assign one if needed.

IMO, it's not CVE worthy.  Unprivileged users can trigger the bug, but the bug
itself is not harmful to the system at large, only to that user's VM/workload.
The splat is a WARN_ON_ONCE() so it won't spam the kernel log.  panic_on_warn
would be problematic, but assigning a CVE for every WARN seems excessive.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-06-17 16:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <ca5aa7c.e8ca9.17f71bde91a.Coremail.pgn@zju.edu.cn>
2022-04-15 21:09 ` 'WARNING in vcpu_enter_guest' bug in arch/x86/kvm/x86.c:9877 Sean Christopherson
     [not found] <25270242.531.1655475119097@app133160.ycg3.service-now.com>
2022-06-17 16:28 ` Sean Christopherson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.