Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [RFC 3/3] KVM: PPC: Book3S HV nestedv2: cap max vcpus to PAPR limit
Date: Fri, 11 Sep 2026 05:11:49 +0000	[thread overview]
Message-ID: <20260911051150.6E7981F000FF@smtp.kernel.org> (raw)
In-Reply-To: <e2c1ef05eaa19beb28a3db08fb697a80528cd43a.1789099725.git.ritesh.list@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] Build failure on non-HV configurations (e.g. BookE or PR-only builds) due to undeclared identifier KVM_MAX_VCPU_IDS_NESTEDv2.

Pre-existing issues:
- [High] The patch correctly caps the reported KVM capabilities for nestedv2 maximum vCPUs and vCPU IDs to 2048, but it fails to enforce this limit during actual vCPU creation. A malicious userspace can bypass the capability check and pass a vcpu_id >= 2048, causing the L0 hypervisor to reject it and triggering an unbounded pr_err() log spam in the host kernel.
--

commit 603e4503cd207cc17d84e5e865ff47b744a57762
Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

KVM: PPC: Book3S HV nestedv2: cap max vcpus to PAPR limit

This commit limits the maximum number of vCPUs and vCPU IDs reported by KVM
for nestedv2 guests to 2048, as dictated by the PAPR specification. It updates
KVM_CAP_NR_VCPUS, KVM_CAP_MAX_VCPUS, and KVM_CAP_MAX_VCPU_ID when
kvmhv_is_nestedv2() is true.

> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 2d139c8075773..d48232557259c 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -37,6 +37,7 @@
>  #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>  #include <asm/kvm_book3s_asm.h>		/* for MAX_SMT_THREADS */
>  #define KVM_MAX_VCPU_IDS	(MAX_SMT_THREADS * KVM_MAX_VCORES)
> +#define KVM_MAX_VCPU_IDS_NESTEDv2	2048	/* PAPR H_GUEST_CREATE_VCPU vcpuId */
>  
>  /*
>   * Limit the nested partition table to 4096 entries (because that's what
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 9194cf492d1ca..cf620b6534de6 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -663,12 +663,18 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  			r = min(num_present_cpus(), KVM_MAX_VCPUS);
>  		else
>  			r = min(num_online_cpus(), KVM_MAX_VCPUS);
> +		if (kvmhv_is_nestedv2())
> +			r = min(r, KVM_MAX_VCPU_IDS_NESTEDv2);

[Severity: Low]
Will this cause a build failure on non-HV configurations?

Since KVM_MAX_VCPU_IDS_NESTEDv2 is defined inside an
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE block in asm/kvm_host.h, but the
KVM_CAP_NR_VCPUS case in kvm_vm_ioctl_check_extension() sits outside of that
#ifdef block, using it unconditionally here could result in an undeclared
identifier error for builds without HV support (like BookE or PR-only).

>  		break;
>  	case KVM_CAP_MAX_VCPUS:
>  		r = KVM_MAX_VCPUS;
> +		if (kvmhv_is_nestedv2())
> +			r = min(r, KVM_MAX_VCPU_IDS_NESTEDv2);
>  		break;
>  	case KVM_CAP_MAX_VCPU_ID:
>  		r = KVM_MAX_VCPU_IDS;
> +		if (kvmhv_is_nestedv2())
> +			r = min(r, KVM_MAX_VCPU_IDS_NESTEDv2);

[Severity: High]
This is a pre-existing issue, but does capping the reported capability prevent
userspace from actually creating vCPUs with IDs >= 2048?

While this patch fixes the capability reporting, a malicious userspace process
can still bypass the capability check and pass a vcpu_id >= 2048 to the
KVM_CREATE_VCPU ioctl.

If this happens, it appears kvm_arch_vcpu_precreate() in
arch/powerpc/kvm/powerpc.c will still allow it:

int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
{
	return 0;
}

This could cause the L0 hypervisor to reject it in
kvmhv_nestedv2_vcpu_create() in arch/powerpc/kvm/book3s_hv_nestedv2.c, which
contains an unratelimited pr_err() log:

	rc = plpar_guest_create_vcpu(0, vcpu->kvm->arch.lpid, vcpu->vcpu_id);

	if (rc != H_SUCCESS) {
		pr_err("KVM: Create Guest vcpu hcall failed, rc=%ld\n", rc);

Could this be used by an unprivileged host user with /dev/kvm access to
trigger an unbounded log spam and cause a local Denial of Service (DoS)?
Should architecture-specific bounds checking be added to
kvm_arch_vcpu_precreate() to reject vcpu_ids >= KVM_MAX_VCPU_IDS_NESTEDv2
before proceeding with vCPU creation?

>  		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1789099725.git.ritesh.list@gmail.com?part=3

      reply	other threads:[~2026-09-11  5:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11  4:56 [RFC 0/3] KVM: PPC: BE guest-exit fixes and nestedv2 vCPU limit Ritesh Harjani (IBM)
2026-09-11  4:56 ` [RFC 1/3] KVM: PPC: Book3S HV: Read EX_DSISR as a 32-bit field on guest exit Ritesh Harjani (IBM)
2026-09-11  4:56 ` [RFC 2/3] KVM: PPC: Book3S: Don't call __ffs() on an empty pending_exceptions bitmap Ritesh Harjani (IBM)
2026-09-11  5:09   ` sashiko-bot
2026-09-11  4:56 ` [RFC 3/3] KVM: PPC: Book3S HV nestedv2: cap max vcpus to PAPR limit Ritesh Harjani (IBM)
2026-09-11  5:11   ` 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=20260911051150.6E7981F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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