Re: [PATCH v8 12/20] KVM: x86: Support REX2-prefixed opcode decode

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 9/30/2026 2:54 PM, sashiko-bot@kernel.org wrote:
> 
>> @@ -4980,6 +5002,12 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len, int
>>   	if (ctxt->rex_bits & REX_W)
>>   		ctxt->op_bytes = 8;
>>   
>> +	/* REX2 opcode is one byte unless M-bit selects the two-byte map */
>> +	if (ctxt->rex_bits & REX_M)
>> +		goto decode_twobytes;
> 
> [Severity: Critical]
> Could this jump to decode_twobytes allow a malicious guest to trigger a host
> kernel panic?
> 
> If a guest constructs an SSE or vector instruction (such as MOVUPS in the
> 0x0F map) prefixed with a REX2 byte (0xD5) where the REX2 payload sets the
> M-bit and an extended register bit like R4, this will jump to
> decode_twobytes and look up the opcode in twobyte_table.
> 
> Because vector instructions in twobyte_table lack the NoRex2 flag, the
> validation check for NoRex2 further down in x86_decode_insn() will pass
> instead of raising #UD.
> 
> The payload bit R4 causes the register index to be >= 16. When evaluating
> the Sse flag:
> 
> arch/x86/kvm/emulate.c:__decode_register_operand() {
> ...
> 	if (ctxt->d & (Avx|Sse)) {
> 		op->type = OP_XMM;
> 		op->bytes = 16;
> 		op->addr.xmm = reg;
> 		kvm_read_sse_reg(reg, &op->vec_val);
> 		return;
> 	}
> ...
> }
> 
> It unconditionally calls kvm_read_sse_reg() with this extended index. The
> index >= 16 falls into the default case in KVM's fpu handling:
> 
> arch/x86/kvm/fpu.h:_kvm_read_sse_reg() {
> ...
> 	case 15: asm("movdqa %%xmm15, %0" : "=m"(*data)); break;
> #endif
> 	default: BUG();
> }
> 
> Does the NoRex2 flag need to be added to vector instructions in twobyte_table
> to prevent this BUG() from being reachable?
> 
>> +	else if (ctxt->rex_prefix == REX2_PREFIX)
>> +		goto decode_onebyte;
>> +
>>   	/* Opcode byte(s). */
>>   	if (ctxt->b == 0xc4 || ctxt->b == 0xc5) {
>>   		/* VEX or LDS/LES */
> 

Patch13 explicitly rejects EVEX instruction, so this path cannot expose
EGPR accesses through VEX instructions.

A similar concern was raised previously, and I gave the same response:
https://lore.kernel.org/kvm/6bdc1a64-0304-4845-a36c-5f309b0b40e0@intel.com/

Thanks,
Chang