Re: [RFC PATCH v2 4/4] KVM: x86: Add optional KVM_EXPORT_VCPU and KVM_IMPORT_VCPU

[Tony Lindgren <tony.lindgren@linux.intel.com>]

On Mon, Aug 31, 2026 at 07:23:53AM +0000, sashiko-bot@kernel.org wrote:
> commit 4d7dccde0750ca7fd34158829ad4120d967ac2c3
> Author: Tony Lindgren <tony.lindgren@linux.intel.com>
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> 
> [ ... ]
> 
> > @@ -6189,6 +6189,38 @@ static int kvm_get_reg_list(struct kvm_vcpu *vcpu,
> >  	return 0;
> >  }
> >  
> > +static int kvm_vcpu_ioctl_transfer_vcpu(struct kvm_vcpu *vcpu, bool import,
> > +					void __user *argp)
> > +{
> > +	struct kvm_vcpu_transfer vcpu_state;
> > +	struct kvm *kvm = vcpu->kvm;
> > +	int r;
> 
> [ ... ]
> 
> > +	if (copy_from_user(&vcpu_state, argp, sizeof(vcpu_state)))
> > +		return -EFAULT;
> > +
> > +	if (vcpu_state.reserved || vcpu_state.buf.reserved)
> > +		return -EINVAL;
> 
> [Severity: High]
> Should we also validate the flags field here to ensure forward compatibility?
> 
> The new kvm_vcpu_transfer structure introduces a flags field, but this
> validation step only explicitly rejects non-zero reserved fields.
> 
> If the kernel silently ignores non-zero flags, userspace might
> inadvertently pass uninitialized or arbitrary values without receiving
> an error. If KVM later assigns meaning to these flags, old userspace
> programs that have been unknowingly passing garbage could unexpectedly
> trigger new behaviors or break.
> 
> Would it be appropriate to require that vcpu_state.flags is zero for now?

Yes flags is unused for vCPU transfers at least for TDX and can be zero
for now.