On Fri, Jun 14, 2024, Mathias Krause wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 14841acb8b95..b04e87f6568f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4200,12 +4200,20 @@ static void kvm_create_vcpu_debugfs(struct kvm_vcpu *vcpu)
> /*
> * Creates some virtual cpus. Good luck creating more than one.
> */
> -static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
> +static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, unsigned long id)
> {
> int r;
> struct kvm_vcpu *vcpu;
> struct page *page;
>
> + /*
> + * KVM tracks vCPU IDs as 'int', be kind to userspace and reject
> + * too-large values instead of silently truncating.
> + *
> + * Also ensure we're not breaking this assumption by accidentally
> + * pushing KVM_MAX_VCPU_IDS above INT_MAX.
I tweaked this slightly because it's not just accidental changes we need to
guard against, and to "hint" that vcpu_id really should be an "unsigned int".
/*
* KVM tracks vCPU IDs as 'int', be kind to userspace and reject
* too-large values instead of silently truncating.
*
* Ensure KVM_MAX_VCPU_IDS isn't pushed above INT_MAX without first
* changing the storage type (at the very least, IDs should be tracked
* as unsigned ints).
*/
> + */
> + BUILD_BUG_ON(KVM_MAX_VCPU_IDS > INT_MAX);
> if (id >= KVM_MAX_VCPU_IDS)
> return -EINVAL;
>
> --
> 2.30.2
>
