Re: [PATCH v3 1/9] KVM: x86: Add helper to provide intercept linear addresses

On 7/30/2026 8:38 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The patch computes `intercept_linear_addr` and adds it to `x86_instruction_info`, but fails to actually use it in the architecture-specific intercept handlers (`svm_check_intercept` and `vmx_check_intercept`), leaving a severe preexisting bug unfixed.
> --
> 
> --- Patch [1]: [PATCH v3 1/9] KVM: x86: Add helper to provide intercept linear addresses ---
> commit e0c208c3018cdb4b9689064eac5e998c1b4d07df
> Author: Tina Zhang <[email protected]>
> 
> KVM: x86: Add helper to provide intercept linear addresses
> 
> This commit adds get_intercept_linear_addr() to compute the linear address
> for INVLPG intercepts. It passes this address through x86_instruction_info
> so intercept handlers can use it directly without duplicating the calculation.
> 
>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>> --- a/arch/x86/kvm/emulate.c
>> +++ b/arch/x86/kvm/emulate.c
> [ ... ]
>> @@ -427,6 +447,7 @@ static int emulator_check_intercept(struct x86_emulate_ctxt *ctxt,
>>   		.src_type   = ctxt->src.type,
>>   		.dst_type   = ctxt->dst.type,
>>   		.ad_bytes   = ctxt->ad_bytes,
>> +		.intercept_linear_addr = get_intercept_linear_addr(ctxt, intercept),
>>   		.rip	    = ctxt->eip,
>>   		.next_rip   = ctxt->_eip,
>>   	};
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but it looks like the architecture
> backends might still need to be updated to consume this new field.
> 
> If an L2 guest executes an INVLPG instruction that KVM intercepts and emulates,
> and L1 is also intercepting INVLPG, the KVM emulator populates
> intercept_linear_addr here.
> 
> However, if the handlers in arch/x86/kvm/svm/svm.c:svm_check_intercept() and
> arch/x86/kvm/vmx/vmx.c:vmx_check_intercept() don't use this new field, does
> KVM synthesize nested VM-exits for INVLPG incorrectly?
> 
> For SVM, if it falls through to the default case and leaves
> vmcb->control.exit_info_1 unmodified, could this leak previous host or
> VM-exit data to the L1 hypervisor?
> 
> For VMX, does lacking a case for x86_intercept_invlpg entirely cause it to
> return X86EMUL_UNHANDLEABLE and fail emulation?
> 
> Should the hardware intercept handlers be updated in this series to prevent
> stale data leakage and L2 DoS?

The SVM consumer is added in patch 2/9.
svm_prepare_decode_assist_exit_info() uses
info->intercept_linear_addr for x86_intercept_invlpg and writes it to
EXITINFO1 before constructing the nested VM-Exit.

The absence of x86_intercept_invlpg handling in vmx_check_intercept()
predates this series.  VMX does not implement SVM DecodeAssists or VMCB
EXITINFO semantics, and patch 1 does not change the existing VMX
behavior.  Supporting emulated nested VMX INVLPG would be a separate
change.

Thanks,
Tina

>