Re: [PATCH v15 16/23] KVM: selftests: Load per-vCPU guest stack in TDX boot parameters

[Lisa Wang <wyihan@google.com>]

On Fri, Oct 02, 2026 at 09:13:36AM +0000, sashiko-bot@kernel.org wrote:
> > +void tdx_vcpu_load_boot_parameters(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> > +{
> > +	struct td_boot_parameters *params =
> > +		addr_gpa2hva(vm, TD_BOOT_PARAMETERS_GPA);
> > +	struct td_per_vcpu_parameters *vcpu_params =
> > +		&params->per_vcpu[vcpu->id];
> 
> [Severity: Medium]
> Will this lead to an out-of-bounds array access in
> tdx_vcpu_load_boot_parameters() if a test uses a sparse vcpu->id?
> 
> The boot parameters region appears to allocate memory for exactly
> nr_runnable_vcpus instances of struct td_per_vcpu_parameters in
> tdx_vm_setup_boot_parameters_region():
> 
>     size_t boot_params_size = sizeof(struct td_boot_parameters) +
>         nr_runnable_vcpus * sizeof(struct td_per_vcpu_parameters);
> 
> Since vcpu->id represents the KVM vCPU ID (which can be the APIC ID on x86)
> and can be larger than or equal to nr_runnable_vcpus, could this write beyond
> the allocated bounds and corrupt adjacent host memory and guest physical pages?
> 
> This could be triggered if a selftest creating a TDX VM specifies a sparse
> vcpu->id that is larger than or equal to the total number of runnable vCPUs
> passed to vm_create().

In KVM selftests, VMs already create vCPUs sequentially with vcpu->id
(via __vm_create_with_vcpus()). TDX selftests will not test sparse vCPU
IDs either, because TDH.VP.INIT always initializes %esi to the sequential
0-based vCPU index.

> > +
> > +	vcpu_params->esp_gva = kvm_allocate_vcpu_stack(vm);
> > +	TEST_ASSERT(vcpu_params->esp_gva < (1ULL << 32),
> > +		    "ESP GVA must be within 32-bit address space for 32-bit boot code");
> 
> [Severity: Medium]
> Does this bounds check in tdx_vcpu_load_boot_parameters() actually work, or is
> the value silently truncated before the check?
> 
> Because kvm_allocate_vcpu_stack() returns a 64-bit gva_t, assigning it
> to vcpu_params->esp_gva truncates the value to 32 bits since esp_gva is
> declared as a u32.
> 
> The TEST_ASSERT then evaluates the already truncated 32-bit value against
> (1ULL << 32), which will always be true. Could this bypass the intended
> safety check and cause silent stack corruption and test failures instead of
> an explicit assertion failure?
> 
> This could be triggered if a selftest allocates enough memory such that the
> guest stack virtual address exceeds 4GB.

Yes, will fix in the next series.