lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <175831174075.709179.17586704180114237934.tip-bot2@tip-bot2>
Date: Fri, 19 Sep 2025 19:55:40 -0000
From: "tip-bot2 for Sean Christopherson" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Dan Snyder <dansnyder@...gle.com>, Sean Christopherson <seanjc@...gle.com>,
 "Borislav Petkov (AMD)" <bp@...en8.de>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>, stable@...r.kernel.org,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: x86/cpu] x86/umip: Check that the instruction opcode is at
 least two bytes

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     32278c677947ae2f042c9535674a7fff9a245dd3
Gitweb:        https://git.kernel.org/tip/32278c677947ae2f042c9535674a7fff9a245dd3
Author:        Sean Christopherson <seanjc@...gle.com>
AuthorDate:    Fri, 08 Aug 2025 10:23:56 -07:00
Committer:     Borislav Petkov (AMD) <bp@...en8.de>
CommitterDate: Fri, 19 Sep 2025 20:21:12 +02:00

x86/umip: Check that the instruction opcode is at least two bytes

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.

Analyzed by Nick Bray <ncbray@...gle.com>.

Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions")
Reported-by: Dan Snyder <dansnyder@...gle.com>
Signed-off-by: Sean Christopherson <seanjc@...gle.com>
Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Cc: stable@...r.kernel.org
---
 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 5a4b213..406ac01 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) {

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ