Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v5 12/12] KVM: SVM: Add support for virtualizating Bus Lock Detect
Date: Wed, 30 Sep 2026 01:36:03 +0000	[thread overview]
Message-ID: <20260930013604.3B1281F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930011313.3197688-13-seanjc@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: x86: Host DoS via WARN_ON_ONCE in kvm_deliver_exception_payload()
--

commit ae1e356a2c3cc9178bead14afcfa89eabb330003
Author: Ravi Bangoria <ravi.bangoria@amd.com>

    KVM: SVM: Add support for virtualizating Bus Lock Detect
    
    Advertise support for virtualizing Bus Lock Detect and allow the guest to
    enable BUS_LOCK_DETECT if LBR Virtualization is enabled (Bus Lock Detect is
    enabled through MSR_IA32_DEBUGCTLMSR, which context-switched if and only if
    LBR Virtualization is enabled).

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 1e58ad8691e92..e7c296c52591f 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
[ ... ]
> @@ -5712,9 +5712,17 @@ static __init void svm_set_cpu_caps(void)
>  	 * Clear capabilities that are automatically configured by common code,
>  	 * but that require explicit SVM support (that isn't yet implemented).
>  	 */
> -	kvm_cpu_cap_clear(X86_FEATURE_BUS_LOCK_DETECT);
>  	kvm_cpu_cap_clear(X86_FEATURE_MSR_IMM);
>  
> +	/*
> +	 * LBR Virtualization must be enabled to support BusLockTrap inside the
> +	 * guest, since BusLockTrap is enabled through MSR_IA32_DEBUGCTLMSR and
> +	 * MSR_IA32_DEBUGCTLMSR is virtualized only if LBR Virtualization is
> +	 * enabled.
> +	 */
> +	if (!lbrv)
> +		kvm_cpu_cap_clear(X86_FEATURE_BUS_LOCK_DETECT);

[Severity: High]
Could exposing X86_FEATURE_BUS_LOCK_DETECT introduce a regression where a
malicious unprivileged userspace process can cause a host denial of service
via WARN_ON_ONCE?

A malicious unprivileged userspace process can call KVM_SET_VCPU_EVENTS
with an exception payload that has bit 11 (DR6_BUS_LOCK) or bit 16
(DR6_RTM) set. This unsanitized payload is accepted and passed into the
vcpu architecture state:

arch/x86/kvm/x86.c:kvm_vcpu_ioctl_x86_set_vcpu_events()
	vcpu->arch.exception.payload = events->exception_payload;

When KVM_RUN injects the exception, it calls kvm_deliver_exception_payload().
Because these bits are within DR6_ACTIVE_LOW, the payload application
clears them from vcpu->arch.dr6.

However, if the guest CPU lacks support for these features, dr6_fixed_1
will have these bits set to 1. The subsequent sanity check evaluates to
true because the bits were just cleared, reliably triggering the WARN_ON_ONCE:

arch/x86/kvm/x86.c:kvm_deliver_exception_payload()
		if (WARN_ON_ONCE((vcpu->arch.dr6 & dr6_fixed_1) != dr6_fixed_1))
			vcpu->arch.dr6 |= dr6_fixed_1;

Any unprivileged process with access to /dev/kvm can trigger this, which
may panic the host if panic_on_warn is set.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930011313.3197688-1-seanjc@google.com?part=12

      reply	other threads:[~2026-09-30  1:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  1:13 [PATCH v5 00/12] KVM: x86: Bus Lock Detect fixes and SVM support Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 01/12] KVM: x86: Preserve DR6.BLD (Bus Lock Detect) when delivering #DB payload Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 02/12] KVM: x86: Rename kvm_dr6_fixed() => kvm_get_dr6_fixed_1() Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 03/12] KVM: Return an "unsigned long", not "u64" for the fixed-1 DR6 bits Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 04/12] KVM: x86: Force fixed-1 bits in DR6 after synchronizing with hardware Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 05/12] KVM: x86: WARN if fixed-1 DR6 bits aren't already set when delivering payload Sean Christopherson
2026-09-30  1:28   ` sashiko-bot
2026-09-30 12:59     ` Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 06/12] KVM: x86: Kill off DR6_FIXED_1 to prevent future misuse Sean Christopherson
2026-09-30  1:28   ` sashiko-bot
2026-09-30  1:13 ` [PATCH v5 07/12] KVM: SVM: Add helper to query if LBR virtualization needs to be enabled Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 08/12] KVM: nSVM: Disable LBRV in nested control cache when unsupported Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 09/12] KVM: nSVM: Open code check on LBR virtualization being enabled in vmcb12 Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 10/12] KVM: nSVM: Don't assume all active-low bits DR6 are fixed-1 Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 11/12] KVM: SVM: Add a vCPU-aware helper to get supported DEBUGCTL bits Sean Christopherson
2026-09-30  1:13 ` [PATCH v5 12/12] KVM: SVM: Add support for virtualizating Bus Lock Detect Sean Christopherson
2026-09-30  1:36   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260930013604.3B1281F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox