]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
KVM: SEV: Reject non-positive effective lengths during LAUNCH_UPDATE
authorSean Christopherson <seanjc@google.com>
Fri, 19 Sep 2025 21:16:49 +0000 (14:16 -0700)
committerSean Christopherson <seanjc@google.com>
Tue, 23 Sep 2025 15:55:20 +0000 (08:55 -0700)
commit5b66e335ead6472f336b4d7d9cbf14488b844f27
tree544f6ea313ba14e26f884254dc89b0d5e5a346b5
parent4135a9a8ccba2b685f2301429ea765fa0f78eb89
KVM: SEV: Reject non-positive effective lengths during LAUNCH_UPDATE

Check for an invalid length during LAUNCH_UPDATE at the start of
snp_launch_update() instead of subtly relying on kvm_gmem_populate() to
detect the bad state.  Code that directly handles userspace input
absolutely should sanitize those inputs; failure to do so is asking for
bugs where KVM consumes an invalid "npages".

Keep the check in gmem, but wrap it in a WARN to flag any bad usage by
the caller.

Note, this is technically an ABI change as KVM would previously allow a
length of '0'.  But allowing a length of '0' is nonsensical and creates
pointless conundrums in KVM.  E.g. an empty range is arguably neither
private nor shared, but LAUNCH_UPDATE will fail if the starting gpa can't
be made private.  In practice, no known or well-behaved VMM passes a
length of '0'.

Note #2, the PAGE_ALIGNED(params.len) check ensures that lengths between
1 and 4095 (inclusive) are also rejected, i.e. that KVM won't end up with
npages=0 when doing "npages = params.len / PAGE_SIZE".

Cc: Thomas Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20250919211649.1575654-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
arch/x86/kvm/svm/sev.c
virt/kvm/guest_memfd.c