From: sashiko-bot@kernel.org
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v6 13/20] KVM: x86: Reject EVEX-prefixed instructions
Date: Wed, 29 Jul 2026 19:58:40 +0000 [thread overview]
Message-ID: <20260729195841.24B9F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729191656.598771-14-chang.seok.bae@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added EVEX prefix check evaluates an uninitialized or stale `ctxt->modrm` byte in 32-bit mode and is entirely redundant because KVM already maps opcode 0x62 to `NotImpl`.
--
--- Patch [13]: [PATCH v6 13/20] KVM: x86: Reject EVEX-prefixed instructions ---
commit 086b81f7f3526e32d2a152bf460681542a47ce74
Author: Chang S. Bae <chang.seok.bae@intel.com>
KVM: x86: Reject EVEX-prefixed instructions
This commit explicitly marks EVEX-prefixed opcodes (0x62) as unsupported
in the x86 instruction emulator.
> 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))
[Severity: Medium]
Could this evaluate an uninitialized or stale ctxt->modrm?
Looking at x86_decode_insn(), since opcode 0x62 is already mapped to
NotImpl in the KVM opcode_table, the opcode.flags & ModRM condition will
be false, and ctxt->modrm will not be fetched just above this check.
When evaluating this in 32-bit mode, would it end up reading an
uninitialized struct member, even though the instruction is already
set to be rejected anyway?
> + opcode.flags = NotImpl;
> +
> done_modrm:
> ctxt->d = opcode.flags;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729191656.598771-1-chang.seok.bae@intel.com?part=13
next prev parent reply other threads:[~2026-07-29 19:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 19:16 [PATCH v6 00/20] KVM: x86: Enable APX for guests Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 01/20] KVM: x86: Extend VCPU registers for EGPRs Chang S. Bae
2026-07-29 20:04 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 02/20] KVM: VMX: Save guest EGPRs in VCPU cache Chang S. Bae
2026-07-29 20:05 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 03/20] KVM: x86: Support APX state for XSAVE ABI Chang S. Bae
2026-07-29 20:31 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 04/20] KVM: VMX: Refactor VMX instruction information access Chang S. Bae
2026-07-29 20:02 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 05/20] KVM: VMX: Refactor instruction information decoding Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 06/20] KVM: VMX: Remove unused control-register access defines Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 07/20] KVM: VMX: Refactor register index retrieval from exit qualification Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 08/20] KVM: VMX: Support instruction information extension Chang S. Bae
2026-07-29 20:00 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 09/20] KVM: nVMX: Propagate extended instruction information Chang S. Bae
2026-07-29 20:01 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 10/20] KVM: x86: Support EGPR accessing and tracking for emulator Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 11/20] KVM: x86: Handle EGPR index and REX2-incompatible opcodes Chang S. Bae
2026-07-29 20:04 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 12/20] KVM: x86: Support REX2-prefixed opcode decode Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 13/20] KVM: x86: Reject EVEX-prefixed instructions Chang S. Bae
2026-07-29 19:58 ` sashiko-bot [this message]
2026-07-29 19:16 ` [PATCH v6 14/20] KVM: x86: Move KVM_SUPPORTED_{XCR0,XSS} into kvm_x86_vendor_init() Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 15/20] KVM: x86: Guard valid XCR0.APX settings Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 16/20] KVM: x86: Add APX to supported XCR0 Chang S. Bae
2026-07-29 20:06 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 17/20] KVM: x86: Expose APX foundation feature to userspace Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 18/20] KVM: x86: Expose APX sub-features " Chang S. Bae
2026-07-29 20:01 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 19/20] KVM: x86: selftests: Add APX state and ABI test Chang S. Bae
2026-07-29 20:08 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 20/20] KVM: x86: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260729195841.24B9F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chang.seok.bae@intel.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox