Re: [RFC PATCH 02/12] drivers: hv: hv_common: Allocate Hyper-V output arg page when VSM is enabled

[Wei Liu <wei.liu@kernel.org>]

On Tue, Sep 01, 2026 at 05:12:38PM +0000, sashiko-bot@kernel.org 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 <tgopinath@linux.microsoft.com>
> 
> 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