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: Wed, 30 Sep 2026 05:20:34 -0700 [thread overview]
Message-ID: <arz-kvd4jWnEFAoq@google.com> (raw)
In-Reply-To: <CAG48ez0zfaEgWoFiLyVLu_ZU8XtJoKVoyMrnxMcLX6e+3j0jgw@mail.gmail.com>
On Wed, Sep 30, 2026, Jann Horn wrote:
> On Mon, Aug 10, 2026 at 6:29 PM Sean Christopherson <seanjc@google.com> wrote:
> > 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?
>
> Ping?
> I still don't see this in mainline or in next.
Ha, I *just* pushed it to kvm-x86/fixes yesterday, it should show up in today's
-next build.
https://github.com/kvm-x86/linux/commit/9e389110fd668958735141af24d04ed040776235
Oof, but it looks like Paolo force-pushed to kvm/master (accidentally?), so I'll
probably rebase it today. I.e. the hash is likely going to change (but I'll
still send it along for 7.4).
next prev parent reply other threads:[~2026-09-30 12:20 UTC|newest]
Thread overview: 6+ 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
2026-09-30 11:01 ` Jann Horn
2026-09-30 12:20 ` Sean Christopherson [this message]
2026-10-02 21:06 ` Sean Christopherson
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=arz-kvd4jWnEFAoq@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.