[PATCH 0/3] KVM: x86: Fix off-by-one in max_vcpu_ids bounds checks

[PATCH 0/3] KVM: x86: Fix off-by-one in max_vcpu_ids bounds checks

[Dmytro Maluka]

max_vcpu_ids and KVM_CAP_MAX_VCPU_ID are exclusive, i.e. the maximum
allowed vcpu_id value is max_vcpu_ids minus one, not max_vcpu_ids.

Fix the sanity checks for KVM_SET_BOOT_CPU_ID and KVM_CAP_MAX_VCPU_ID
and the selftests for them (added in series [1]) to fail when
bsp_vcpu_id is incorrectly set to max_vcpu_ids, not to a value below
max_vcpu_ids.

Also clarify that in the documentation of KVM_CAP_MAX_VCPU_ID, in an
attempt to make this a bit less confusing.

[1] https://lore.kernel.org/all/20240614202859.3597745-1-minipli@grsecurity.net/

Dmytro Maluka (3):
  KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive
  KVM: x86: Fix off-by-one in max_vcpu_ids bounds checks
  Documentation: KVM: Clarify that KVM_CAP_MAX_VCPU_ID is exclusive

 Documentation/virt/kvm/api.rst                  | 13 ++++++++-----
 arch/x86/kvm/x86.c                              |  6 +++---
 .../selftests/kvm/x86/max_vcpuid_cap_test.c     | 17 ++++++++++-------
 .../testing/selftests/kvm/x86/set_boot_cpu_id.c |  4 ++--
 4 files changed, 23 insertions(+), 17 deletions(-)

-- 
2.55.0.508.g3f0d502094-goog

[PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive

[Dmytro Maluka]

KVM_CAP_MAX_VCPU_ID is (confusingly) exclusive, i.e. the maximum allowed
vcpu_id value is KVM_CAP_MAX_VCPU_ID minus one.

Some tests in x86/max_vcpuid_cap_test.c and kvm/x86/set_boot_cpu_id.c
mistakenly treat it as inclusive, in particular, assume that setting
bsp_vcpu_id to KVM_CAP_MAX_VCPU_ID is valid and should succeed. Fix
those tests.

Fixes: 4b451a57809c ("KVM: selftests: Test max vCPU IDs corner cases")
Fixes: 438a496b9041 ("KVM: selftests: Test vCPU boot IDs above 2^32 and MAX_VCPU_ID")
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
---
 .../selftests/kvm/x86/max_vcpuid_cap_test.c     | 17 ++++++++++-------
 .../testing/selftests/kvm/x86/set_boot_cpu_id.c |  4 ++--
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
index 7e2bfb3c3f3b..43f16c052de4 100644
--- a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
+++ b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
@@ -30,22 +30,25 @@ int main(int argc, char *argv[])
 	if (kvm_has_cap(KVM_CAP_SET_BOOT_CPU_ID)) {
 		vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)MAX_VCPU_ID);
 
-		/* Try setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID */
-		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID - 1);
+		/* Try setting KVM_CAP_MAX_VCPU_ID below or equal to BOOT_CPU_ID */
+		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
 		TEST_ASSERT(ret < 0,
-			    "Setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID should fail");
+			    "Setting KVM_CAP_MAX_VCPU_ID <= BOOT_CPU_ID should fail");
 	}
 
-	/* Set KVM_CAP_MAX_VCPU_ID */
-	vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
+	/*
+	 * Set KVM_CAP_MAX_VCPU_ID. Note: KVM_CAP_MAX_VCPU_ID is a misnomer,
+	 * it actually represents maximum vcpu_id plus one.
+	 */
+	vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 1);
 
 	/* Try to set KVM_CAP_MAX_VCPU_ID again */
-	ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 1);
+	ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 2);
 	TEST_ASSERT(ret < 0,
 		    "Setting KVM_CAP_MAX_VCPU_ID multiple times should fail");
 
 	/* Create vCPU with id beyond KVM_CAP_MAX_VCPU_ID cap */
-	ret = __vm_ioctl(vm, KVM_CREATE_VCPU, (void *)MAX_VCPU_ID);
+	ret = __vm_ioctl(vm, KVM_CREATE_VCPU, (void *)(MAX_VCPU_ID + 1));
 	TEST_ASSERT(ret < 0, "Creating vCPU with ID > MAX_VCPU_ID should fail");
 
 	/* Create vCPU with bits 63:32 != 0, but an otherwise valid id */
diff --git a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
index 8e3898646c69..1c4ebdf8e82c 100644
--- a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
+++ b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
@@ -39,8 +39,8 @@ static void test_set_invalid_bsp(struct kvm_vm *vm)
 	int r;
 
 	if (max_vcpu_id) {
-		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(max_vcpu_id + 1));
-		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID > MAX should fail");
+		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)max_vcpu_id);
+		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID >= MAX should fail");
 	}
 
 	r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(1L << 32));
-- 
2.55.0.508.g3f0d502094-goog

[PATCH 2/3] KVM: x86: Fix off-by-one in max_vcpu_ids bounds checks

[Dmytro Maluka]

max_vcpu_ids and KVM_CAP_MAX_VCPU_ID are exclusive, i.e. the maximum
allowed vcpu_id value is max_vcpu_ids minus one, not max_vcpu_ids.

Fix sanity checks for KVM_SET_BOOT_CPU_ID and KVM_CAP_MAX_VCPU_ID to
fail when bsp_vcpu_id is incorrectly set to max_vcpu_ids, not to a value
below max_vcpu_ids.

Fixes: 7c305d5118e6 ("KVM: x86: Limit check IDs for KVM_SET_BOOT_CPU_ID")
Fixes: d29bf2ca1404 ("KVM: x86: Prevent excluding the BSP on setting max_vcpu_ids")
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
---
 arch/x86/kvm/x86.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 47cb9eba113b..b576b46869d2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6908,7 +6908,7 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
 			break;
 
 		mutex_lock(&kvm->lock);
-		if (kvm->arch.bsp_vcpu_id > cap->args[0]) {
+		if (kvm->arch.bsp_vcpu_id >= cap->args[0]) {
 			;
 		} else if (kvm->arch.max_vcpu_ids == cap->args[0]) {
 			r = 0;
@@ -7478,8 +7478,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
 		mutex_lock(&kvm->lock);
 		if (kvm->created_vcpus)
 			r = -EBUSY;
-		else if (arg > KVM_MAX_VCPU_IDS ||
-			 (kvm->arch.max_vcpu_ids && arg > kvm->arch.max_vcpu_ids))
+		else if (arg >= KVM_MAX_VCPU_IDS ||
+			 (kvm->arch.max_vcpu_ids && arg >= kvm->arch.max_vcpu_ids))
 			r = -EINVAL;
 		else
 			kvm->arch.bsp_vcpu_id = arg;
-- 
2.55.0.508.g3f0d502094-goog

[PATCH 3/3] Documentation: KVM: Clarify that KVM_CAP_MAX_VCPU_ID is exclusive

[Dmytro Maluka]

The KVM_CAP_MAX_VCPU_ID capability value is exclusive, i.e. valid APIC
ID values are only values below this value, not including it. Its
documentation doesn't make that clear, and even suggests otherwise.
Fix it and explicitly state that it is exclusive.

Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
---
 Documentation/virt/kvm/api.rst | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index e3003a241d5b..dab9a28c0fb5 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -8593,21 +8593,24 @@ KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT        By default, KVM for nested SVM guests
 
 :Architectures: x86
 :Target: VM
-:Parameters: args[0] - maximum APIC ID value set for current VM
+:Parameters: args[0] - maximum APIC ID value (plus one) set for current VM
 :Returns: 0 on success, -EINVAL if args[0] is beyond KVM_MAX_VCPU_IDS
           supported in KVM or if it has been set.
 
-This capability allows userspace to specify maximum possible APIC ID
+This capability allows userspace to specify a limit on APIC ID values
 assigned for current VM session prior to the creation of vCPUs, saving
 memory for data structures indexed by the APIC ID.  Userspace is able
 to calculate the limit to APIC ID values from designated
 CPU topology.
 
-The value can be changed only until KVM_ENABLE_CAP is set to a nonzero
+The limit is not inclusive, i.e. the maximum possible APIC ID value is
+args[0] - 1.
+
+The capability value can only be changed until it is set to a nonzero
 value or until a vCPU is created.  Upon creation of the first vCPU,
 if the value was set to zero or KVM_ENABLE_CAP was not invoked, KVM
-uses the return value of KVM_CHECK_EXTENSION(KVM_CAP_MAX_VCPU_ID) as
-the maximum APIC ID.
+uses the return value of KVM_CHECK_EXTENSION(KVM_CAP_MAX_VCPU_ID) - 1
+as the maximum APIC ID.
 
 7.33 KVM_CAP_X86_NOTIFY_VMEXIT
 ------------------------------
-- 
2.55.0.508.g3f0d502094-goog

Re: [PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The selftest changes assert that setting `bsp_vcpu_id` equal to `max_vcpu_ids` (the exclusive upper bound for vcpu IDs) will be rejected with `-EINVAL`, but the KVM kernel code was not fixed to enforce this and still returns success, causing the tests to fail.
--

--- Patch [1]: [PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive ---
commit 985e68429c6e20e59d983752bd84f5dc599b83f0
Author: Dmytro Maluka <dmaluka@chromium.org>

KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive

This commit updates KVM selftests to treat KVM_CAP_MAX_VCPU_ID as
exclusive rather than inclusive. It modifies the tests to assert that
setting a boot CPU ID or vCPU ID equal to or greater than the maximum
capacity will fail.

> diff --git a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> index 7e2bfb3c3f3ba..43f16c052de4a 100644
> --- a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> +++ b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> @@ -30,22 +30,25 @@ int main(int argc, char *argv[])
>  	if (kvm_has_cap(KVM_CAP_SET_BOOT_CPU_ID)) {
>  		vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)MAX_VCPU_ID);
>  
> -		/* Try setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID */
> -		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID - 1);
> +		/* Try setting KVM_CAP_MAX_VCPU_ID below or equal to BOOT_CPU_ID */
> +		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
>  		TEST_ASSERT(ret < 0,
> -			    "Setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID should fail");
> +			    "Setting KVM_CAP_MAX_VCPU_ID <= BOOT_CPU_ID should fail");

[Severity: Medium]
Will this assertion now fail because the kernel code hasn't been updated to
enforce this behavior?

Looking at how KVM_CAP_MAX_VCPU_ID is handled in the kernel, it checks:

    if (kvm->arch.bsp_vcpu_id > cap->args[0]) {
        r = -EINVAL;
        break;
    }

If both kvm->arch.bsp_vcpu_id and cap->args[0] are set to MAX_VCPU_ID, the
greater-than condition evaluates to false. Will the ioctl return success
instead of -EINVAL, causing this test to crash?

[ ... ]

> diff --git a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> index 8e3898646c69d..1c4ebdf8e82c5 100644
> --- a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> +++ b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> @@ -39,8 +39,8 @@ static void test_set_invalid_bsp(struct kvm_vm *vm)
>  	int r;
>  
>  	if (max_vcpu_id) {
> -		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(max_vcpu_id + 1));
> -		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID > MAX should fail");
> +		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)max_vcpu_id);
> +		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID >= MAX should fail");

[Severity: Medium]
Does this change also cause the test to fail against the current kernel?

Looking at the KVM_SET_BOOT_CPU_ID handling in arch/x86/kvm/x86.c:kvm_vm_ioctl():

    else if (arg > KVM_MAX_VCPU_IDS ||
             (kvm->arch.max_vcpu_ids && arg > kvm->arch.max_vcpu_ids))
        r = -EINVAL;

Since the kernel checks if arg is greater than max_vcpu_ids instead of
greater than or equal to, will setting arg to max_vcpu_id return success
here and trigger the TEST_ASSERT failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730182425.1223530-1-dmaluka@chromium.org?part=1

Re: [PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive

[Dmytro Maluka]

On Thu, Jul 30, 2026 at 06:52:43PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The selftest changes assert that setting `bsp_vcpu_id` equal to `max_vcpu_ids` (the exclusive upper bound for vcpu IDs) will be rejected with `-EINVAL`, but the KVM kernel code was not fixed to enforce this and still returns success, causing the tests to fail.
> --
> 
> --- Patch [1]: [PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive ---
> commit 985e68429c6e20e59d983752bd84f5dc599b83f0
> Author: Dmytro Maluka <dmaluka@chromium.org>
> 
> KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive
> 
> This commit updates KVM selftests to treat KVM_CAP_MAX_VCPU_ID as
> exclusive rather than inclusive. It modifies the tests to assert that
> setting a boot CPU ID or vCPU ID equal to or greater than the maximum
> capacity will fail.
> 
> > diff --git a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> > index 7e2bfb3c3f3ba..43f16c052de4a 100644
> > --- a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> > +++ b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
> > @@ -30,22 +30,25 @@ int main(int argc, char *argv[])
> >  	if (kvm_has_cap(KVM_CAP_SET_BOOT_CPU_ID)) {
> >  		vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)MAX_VCPU_ID);
> >  
> > -		/* Try setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID */
> > -		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID - 1);
> > +		/* Try setting KVM_CAP_MAX_VCPU_ID below or equal to BOOT_CPU_ID */
> > +		ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
> >  		TEST_ASSERT(ret < 0,
> > -			    "Setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID should fail");
> > +			    "Setting KVM_CAP_MAX_VCPU_ID <= BOOT_CPU_ID should fail");
> 
> [Severity: Medium]
> Will this assertion now fail because the kernel code hasn't been updated to
> enforce this behavior?
> 
> Looking at how KVM_CAP_MAX_VCPU_ID is handled in the kernel, it checks:
> 
>     if (kvm->arch.bsp_vcpu_id > cap->args[0]) {
>         r = -EINVAL;
>         break;
>     }
> 
> If both kvm->arch.bsp_vcpu_id and cap->args[0] are set to MAX_VCPU_ID, the
> greater-than condition evaluates to false. Will the ioctl return success
> instead of -EINVAL, causing this test to crash?
> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> > index 8e3898646c69d..1c4ebdf8e82c5 100644
> > --- a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> > +++ b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
> > @@ -39,8 +39,8 @@ static void test_set_invalid_bsp(struct kvm_vm *vm)
> >  	int r;
> >  
> >  	if (max_vcpu_id) {
> > -		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(max_vcpu_id + 1));
> > -		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID > MAX should fail");
> > +		r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)max_vcpu_id);
> > +		TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID >= MAX should fail");
> 
> [Severity: Medium]
> Does this change also cause the test to fail against the current kernel?
> 
> Looking at the KVM_SET_BOOT_CPU_ID handling in arch/x86/kvm/x86.c:kvm_vm_ioctl():
> 
>     else if (arg > KVM_MAX_VCPU_IDS ||
>              (kvm->arch.max_vcpu_ids && arg > kvm->arch.max_vcpu_ids))
>         r = -EINVAL;
> 
> Since the kernel checks if arg is greater than max_vcpu_ids instead of
> greater than or equal to, will setting arg to max_vcpu_id return success
> here and trigger the TEST_ASSERT failure?

Yeah, I should split this selftest patch into two: the changes which
prevent the KVM fix from breaking the test (and thus should go before
the KVM fix) and the changes which break the test unless the KVM fix is
applied (and thus should go after).