Re: [PATCH 02/24] KVM: SEV: Ignore MMIO requests of length '0'

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A malicious SEV-ES guest can flood the host kernel log and cause a Denial of Service by repeatedly triggering un-ratelimited `pr_err()` prints via invalid GHCB scratch configurations.
--

commit 294af95cb303ec47ddd0734af250cb6201c6779d
Author: Sean Christopherson <seanjc@google.com>

KVM: SEV: Ignore MMIO requests of length '0'

This commit explicitly ignores MMIO requests of length 0. This prevents
underflowing the length when setting up the software scratch area and
allows for special casing 0 in the future.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 23170b64f4a33..fb2174b6d1ba4 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -4497,13 +4497,17 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)
>  	case SVM_VMGEXIT_MMIO_READ:
>  	case SVM_VMGEXIT_MMIO_WRITE: {
>  		bool is_write = control->exit_code == SVM_VMGEXIT_MMIO_WRITE;
> +		u64 len = control->exit_info_2;
>  
> -		ret = setup_vmgexit_scratch(svm, !is_write, control->exit_info_2);
> +		if (!len)
> +			return 1;
> +
> +		ret = setup_vmgexit_scratch(svm, !is_write, len);

[Severity: High]
This isn't a bug introduced by this patch, but could this lead to a host
denial of service through printk flooding?

Looking at setup_vmgexit_scratch() in arch/x86/kvm/svm/sev.c, there are
several validation checks on guest-controlled values that use pr_err()
without ratelimiting:

arch/x86/kvm/svm/sev.c:setup_vmgexit_scratch() {
    ...
	scratch_gpa_beg = svm->sev_es.sw_scratch;
	if (!scratch_gpa_beg) {
		pr_err("vmgexit: scratch gpa not provided\n");
		goto e_scratch;
	}

	scratch_gpa_end = scratch_gpa_beg + len;
	if (scratch_gpa_end < scratch_gpa_beg) {
		pr_err("vmgexit: scratch length (%#llx) not valid for scratch address (%#llx)\n",
		       len, scratch_gpa_beg);
		goto e_scratch;
	}
    ...
}

Since these failure paths gracefully return to the guest with an error code
rather than terminating the VM, an unprivileged guest can trigger these
paths in a tight loop.

For instance, by repeatedly setting sw_scratch to 0 and issuing an MMIO
write request, the guest can flood the host kernel log.

Should these messages be converted to pr_err_ratelimited() or removed
entirely to prevent guest-triggered spam?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529183549.1104619-1-pbonzini@redhat.com?part=2