Re: [BUG] uninitialised stack memory copied to vmcs12

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.07.2026 00:06, Johann Höpfner wrote:
> Hello xen-devel@
> 
> While fuzzing Xen instrumented by an experimental memory sanitizer, we
> discovered the following bug in nested VMX, where a malicious L1 guest
> with nestedhvm=1 can read four uninitialised bytes from the hypervisor
> vmexit handler stack. 
> 
> Specifically nvmx_handle_vmwrite leaves local eight byte variable
> 'operand' uninitialised. It is then written to by decode_vmx_inst. In
> cases where the operand to vmwrite is a r32, r64 or m64, this fully
> initializes *poperandS; if however a vmwrite with a 32 bit memory
> operand is emulated, hvm_copy_from_guest_linear leaves the upper half of
> *poperandS uninitialised. In the case where cpu_has_vmx_shadow_vmcs
> returns true, the resulting eight byte value is consequently written to
> the vmcs12 unchecked and leaks the four uninitialised bytes into guest
> physical memory via the vmcs12.
> 
> Attached is a reproducer for XTF which triggers the behavior described
> above at least on 4.20 and master versions of Xen running on intel
> x86_64 hosts. We would expect there to be the constant 0x99999999, which
> we have just vmwritten, somewhere in the unloaded vmcs12, likely zero
> extended to eight bytes. However it is stored instead alongside four
> bytes read from the hypervisor stack. Currently I am not aware of
> security implications for this bug, as I have not been able to leak more
> than what appear to be the rather uninteresting upper four bytes of a
> pointer.

As to security implications: nested-virt is still experimental, so there's
no formal concern there. In more general terms though, unless you're
certain there's no security aspect to an issue, please instead report more
privately to security@xxxxxxxxxxxxxx.

> The same issue exists in nvmx_handle_invept, though no malicious use is
> known to me. I suggest fixing both by simply initialising operand / eptp
> to 0 in nvmx_handle_vmwrite / nvmx_handle_invept. Patch is given
> immediately below, preceding the reproducer.

You may have noticed that you were able to repro (normally) only with a
hvm32 xtf test. That's because of a bug fixed by [1], which sadly still
didn't make it in. That same bug affects INVEPT and INVVPID. Imo ...

> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1968,7 +1968,7 @@ static int nvmx_handle_vmwrite(struct cpu_user_regs 
> *regs)
>  {
>      struct vcpu *v = current;
>      struct vmx_inst_decoded decode;
> -    unsigned long operand; 
> +    unsigned long operand = 0;
>      u64 vmcs_encoding;
>      enum vmx_insn_errno err;
>      int rc;
> @@ -2012,7 +2012,7 @@ static int nvmx_handle_vmwrite(struct cpu_user_regs 
> *regs)
>  static int nvmx_handle_invept(struct cpu_user_regs *regs)
>  {
>      struct vmx_inst_decoded decode;
> -    unsigned long eptp;
> +    unsigned long eptp = 0;
>      int ret;
>  
>      if ( (ret = decode_vmx_inst(regs, &decode, &eptp)) != X86EMUL_OKAY )

... the INVVPID case wants the same change to be made, even if the local
variable isn't used right now. Otoh the need for the INVEPT and INVVPID
changes goes away with [1] applied, as the size of their memory operand
really doesn't depend on operand or address size.

In any event - why don't you make your proposed change into a proper patch
(primary piece missing is your S-o-b, and perhaps we also would want a
suitable Fixes: tag)?

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01212.html