Re: [PATCH v5 13/20] KVM: x86: Reject EVEX-prefixed instructions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The EVEX prefix check evaluates `ctxt->modrm` without ensuring the ModRM byte was fetched, resulting in a read of stale data, and acts as entirely dead code.
--

--- Patch [13]: [PATCH v5 13/20] KVM: x86: Reject EVEX-prefixed instructions ---
commit fbeae1bf78a009984ff1eb258601fe615d601296
Author: Chang S. Bae <chang.seok.bae@intel.com>

KVM: x86: Reject EVEX-prefixed instructions

Explicitly mark EVEX-prefixed opcodes (0x62) as unsupported.

> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index cb075bd74f769..fc7f9f17c1da4 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -5045,6 +5045,11 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len, int
>  	if (opcode.flags & ModRM)
>  		ctxt->modrm = insn_fetch(u8, ctxt);
>  
> +	/* EVEX-prefixed instructions are not implemented */
> +	if (ctxt->opcode_len == 1 && ctxt->b == 0x62 &&
> +	    (mode == X86EMUL_MODE_PROT64 || (ctxt->modrm & 0xc0) == 0xc0))
> +		opcode.flags = NotImpl;

[Severity: Low]
Does this evaluate stale data in ctxt->modrm?

When a 32-bit guest executes an instruction starting with 0x62 in
x86_decode_insn(), opcode_table[0x62] yields NotImpl, which lacks the ModRM
flag. Because the ModRM flag is missing, insn_fetch() is bypassed.

Since the EVEX check doesn't short-circuit in 32-bit mode, it will evaluate
whatever stale data remains in ctxt->modrm from a prior emulation on that
context.

Because opcode.flags is already initialized to NotImpl by the table lookup,
is this check entirely redundant?

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