* [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
@ 2026-08-10 15:33 Jann Horn
2026-08-10 16:29 ` Sean Christopherson
0 siblings, 1 reply; 2+ messages in thread
From: Jann Horn @ 2026-08-10 15:33 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: Ackerley Tng, kvm, linux-kernel, Matthew Wilcox (Oracle),
Jan Kara, Jann Horn
set_page_dirty() requires that the caller holds some kind of lock to
ensure that the page's mapping does not concurrently go away.
That is not the case for a random page we got from get_user_pages_fast(),
so use set_page_dirty_lock().
Fixes: 97cd21d57e9b ("KVM: SEV: Mark source page dirty when writing back CPUID data on failure")
Signed-off-by: Jann Horn <jannh@google.com>
---
Note that I have only convinced myself that this is a UAF bug by reading
the source code, and I have only compile-tested this patch; I do not
have SEV-SNP hardware to actually test this.
This bug was introduced in v7.2-rc1, so if we can get the fix in before
the 7.2 release, this won't require a stable backport.
For context, I have seen similar bugs (set_page_dirty() on a page from
GUP) in two out-of-tree drivers in the past, where this led to UAF.
Evidently set_page_dirty() is a bit of a footgun for GUP users...
---
arch/x86/kvm/svm/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 0f0ea7896af5..49feef14787a 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2389,7 +2389,7 @@ static int sev_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
void *dst_vaddr = kmap_local_pfn(pfn);
memcpy(src_vaddr, dst_vaddr, PAGE_SIZE);
- set_page_dirty(src_page);
+ set_page_dirty_lock(src_page);
kunmap_local(dst_vaddr);
kunmap_local(src_vaddr);
---
base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
change-id: 20260810-x86-kvm-setpagedirty-a04e49f066f0
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
2026-08-10 15:33 [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate() Jann Horn
@ 2026-08-10 16:29 ` Sean Christopherson
0 siblings, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2026-08-10 16:29 UTC (permalink / raw)
To: Jann Horn
Cc: Paolo Bonzini, Ackerley Tng, kvm, linux-kernel,
Matthew Wilcox (Oracle), Jan Kara
On Mon, Aug 10, 2026, Jann Horn wrote:
> set_page_dirty() requires that the caller holds some kind of lock to
> ensure that the page's mapping does not concurrently go away.
> That is not the case for a random page we got from get_user_pages_fast(),
> so use set_page_dirty_lock().
FWIW, I verified that __kvm_gmem_populate() unlocks the destination folio before
post_populate(), so we shouldn't run into deadlock when in-place conversion comes
along and userspace does something odd.
> Fixes: 97cd21d57e9b ("KVM: SEV: Mark source page dirty when writing back CPUID data on failure")
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
> Note that I have only convinced myself that this is a UAF bug by reading
> the source code, and I have only compile-tested this patch; I do not
> have SEV-SNP hardware to actually test this.
>
> This bug was introduced in v7.2-rc1, so if we can get the fix in before
> the 7.2 release, this won't require a stable backport.
Ya, that would be lovely. Paolo?
> For context, I have seen similar bugs (set_page_dirty() on a page from
> GUP) in two out-of-tree drivers in the past, where this led to UAF.
> Evidently set_page_dirty() is a bit of a footgun for GUP users...
Heh, and that's a bit of an understatement :-D
Reviewed-by: Sean Christopherson <seanjc@google.com>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-10 16:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-10 15:33 [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate() Jann Horn
2026-08-10 16:29 ` Sean Christopherson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox