From: Sean Christopherson <seanjc@google.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org
Cc: linux-kernel@vger.kernel.org, Dan Snyder <dansnyder@google.com>,
Sean Christopherson <seanjc@google.com>
Subject: [PATCH 1/3] x86/umip: Check that the instruction opcode is at least two bytes
Date: Fri, 8 Aug 2025 10:23:56 -0700 [thread overview]
Message-ID: <20250808172358.1938974-2-seanjc@google.com> (raw)
In-Reply-To: <20250808172358.1938974-1-seanjc@google.com>
When checking for a potential UMIP violation on #GP, verify the decoder
found at least two opcode bytes to avoid false positives when the kernel
encounters an unknown instruction that starts with 0f. Because the array
of opcode.bytes is zero-initialized by insn_init(), peeking at bytes[1]
will misinterpret garbage as a potential SLDT or STR instruction, and can
incorrectly trigger emulation.
E.g. if a vpalignr instruction
62 83 c5 05 0f 08 ff vpalignr xmm17{k5},xmm23,XMMWORD PTR [r8],0xff
hits a #GP, the kernel emulates it as STR and squashes the #GP (and
corrupts the userspace code stream).
Arguably the check should look for exactly two bytes, but no three byte
opcodes use '0f 00 xx' or '0f 01 xx' as an escape, i.e. it should be
impossible to get a false positive if the first two opcode bytes match
'0f 00' or '0f 01'. Go with a more conservative check with respect to the
existing code to minimize the chances of breaking userspace, e.g. due to
decoder weirdness.
Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions")
Reported-by: Dan Snyder <dansnyder@google.com>
Analyzed-by; Nick Bray <ncbray@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kernel/umip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index 5a4b21389b1d..406ac01ce16d 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -156,8 +156,8 @@ static int identify_insn(struct insn *insn)
if (!insn->modrm.nbytes)
return -EINVAL;
- /* All the instructions of interest start with 0x0f. */
- if (insn->opcode.bytes[0] != 0xf)
+ /* The instructions of interest have 2-byte opcodes: 0F 00 or 0F 01. */
+ if (insn->opcode.nbytes < 2 || insn->opcode.bytes[0] != 0xf)
return -EINVAL;
if (insn->opcode.bytes[1] == 0x1) {
--
2.50.1.703.g449372360f-goog
next prev parent reply other threads:[~2025-08-08 17:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 17:23 [PATCH 0/3] x86/umip: Fix UMIP insn decoder false positives Sean Christopherson
2025-08-08 17:23 ` Sean Christopherson [this message]
2025-08-14 14:42 ` [PATCH 1/3] x86/umip: Check that the instruction opcode is at least two bytes Peter Zijlstra
2025-09-19 18:16 ` Borislav Petkov
2025-09-19 21:24 ` Sean Christopherson
2025-09-20 10:07 ` Borislav Petkov
2025-09-19 19:55 ` [tip: x86/cpu] " tip-bot2 for Sean Christopherson
2025-08-08 17:23 ` [PATCH 2/3] x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT aliases) Sean Christopherson
2025-08-14 14:42 ` Peter Zijlstra
2025-09-19 19:55 ` [tip: x86/cpu] " tip-bot2 for Sean Christopherson
2025-08-08 17:23 ` [PATCH 3/3] *** DO NOT MERGE *** x86/umip: Lazy person's KUnit test for UMIP emulation Sean Christopherson
2025-09-19 14:31 ` [PATCH 0/3] x86/umip: Fix UMIP insn decoder false positives Sean Christopherson
2025-09-19 14:46 ` Borislav Petkov
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=20250808172358.1938974-2-seanjc@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dansnyder@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.