From: Sean Christopherson <seanjc@google.com>
To: Jann Horn <jannh@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Ackerley Tng <ackerleytng@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
Date: Mon, 10 Aug 2026 09:29:28 -0700 [thread overview]
Message-ID: <ann8aPLSgLzz_6L_@google.com> (raw)
In-Reply-To: <20260810-x86-kvm-setpagedirty-v1-1-85f180892d4f@google.com>
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>
prev parent reply other threads:[~2026-08-10 16:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 15:33 [PATCH] KVM: SEV: Fix page dirtying in sev_gmem_post_populate() Jann Horn
2026-08-10 15:50 ` sashiko-bot
2026-08-10 16:29 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ann8aPLSgLzz_6L_@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox