On Tue, Sep 01, 2026 at 05:12:38PM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > > Pre-existing issues: > - [High] hv_apicid_to_vp_index() unconditionally dereferences the unallocated > hyperv_pcpu_output_arg pointer in standard/SNP guests. > -- > > commit 0ee3313e113c9ca7969923f2af5a1ed18ddb25d2 > Author: Thara Gopinath <[email protected]> > > drivers: hv: hv_common: Allocate Hyper-V output arg page when VSM is enabled > > This commit extends hv_output_page_exists() to return true when > CONFIG_HYPERV_VSM is enabled. This ensures the per-CPU output argument > page is allocated at boot for VSM hypercalls. > > > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c > > index 31256cb22b39e..44f4a10984618 100644 > > --- a/drivers/hv/hv_common.c > > +++ b/drivers/hv/hv_common.c > > @@ -259,7 +259,8 @@ static void hv_kmsg_dump_register(void) > > > > static inline bool hv_output_page_exists(void) > > { > > - return hv_parent_partition() || IS_ENABLED(CONFIG_HYPERV_VTL_MODE); > > + return hv_parent_partition() || IS_ENABLED(CONFIG_HYPERV_VTL_MODE) || > > + IS_ENABLED(CONFIG_HYPERV_VSM); > > [Severity: High] > This is a pre-existing issue, but modifying this function highlights a > vulnerability for SEV-SNP guests where VSM and VTL modes are disabled. > > When an SEV-SNP guest boots secondary CPUs, hv_smp_prepare_cpus() overrides > the wakeup callback with hv_snp_boot_ap(), which then calls > hv_apicid_to_vp_index() in arch/x86/hyperv/ivm.c. > > If CONFIG_HYPERV_VSM and CONFIG_HYPERV_VTL_MODE are both disabled, > hv_output_page_exists() evaluates to false. This means hyperv_pcpu_output_arg > is never allocated during hv_common_init() and remains NULL. > > Consequently, arch/x86/hyperv/hv_init.c:hv_apicid_to_vp_index() dereferences > this unallocated pointer: > > arch/x86/hyperv/hv_init.c:hv_apicid_to_vp_index() { > ... > output = *this_cpu_ptr(hyperv_pcpu_output_arg); > ... > status = hv_do_hypercall(HVCALL_GET_VP_ID_FROM_APIC_ID, input, > output); > ... > } > > Since this_cpu_ptr(NULL) resolves to the base of the per-CPU area, it > dereferences a garbage pointer. This is then passed to hv_do_hypercall(), > causing the hypervisor to overwrite random physical memory with the hypercall > result, and eventually oopsing the kernel when output[0] is read. >
This looks like a real bug. It should / will be fixed separately. Wei
