Re: [PATCH v8 03/20] KVM: x86: Support APX state for XSAVE ABI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] x86/kvm: stale APX registers (R16-R31) on KVM_SET_XSAVE
--

commit 589bfa90166bba201eeea61923abb798785e7f3a
Author: Chang S. Bae <chang.seok.bae@intel.com>

KVM: x86: Support APX state for XSAVE ABI

This commit introduces a facility to copy APX state between the VCPU cache
and the userspace buffer. It establishes copy functions to ensure APX state
is properly handled during user ABI interactions.

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 79468ddfe4736..0df74422759f8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c

[ ... ]

> +static int kvm_copy_uabi_to_vcpu_regs(struct kvm_vcpu *vcpu, void *buf, u64 supported_xcr0)
> +{
> +	union fpregs_state *xstate = (union fpregs_state *)buf;
> +
> +	if (!(xstate->xsave.header.xfeatures & XFEATURE_MASK_APX))
> +		return 0;

[Severity: High]
Does this early return leave stale values in the APX registers instead of
initializing them to zero?

When a guest is restored via KVM_SET_XSAVE and the XSAVE payload indicates
the APX state is in its INIT state (the APX bit in the header is 0),
returning early here bypasses zeroing the extended general purpose
registers in vcpu->arch.regs. This can lead to guest state corruption
across snapshot restores or live migration, as the guest might observe
stale non-zero values in R16-R31 when it expects them to be zero.

> +
> +	if (!(supported_xcr0 & XFEATURE_MASK_APX))
> +		return -EINVAL;
> +
> +	BUILD_BUG_ON(NR_VCPU_GENERAL_PURPOSE_REGS <= VCPU_REGS_R31);
> +
> +	memcpy(&vcpu->arch.regs[VCPU_REGS_R16],
> +	       buf + xstate_offset(XFEATURE_APX),
> +	       xstate_size(XFEATURE_APX));
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930210750.1487547-1-chang.seok.bae@intel.com?part=3