From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 4/7] KVM: Rework .gmem_invalidate() into .gmem_free_folio()
Date: Thu, 25 Jun 2026 22:39:19 +0000 [thread overview]
Message-ID: <20260625223920.6C7511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260625222229.3367197-5-seanjc@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] KVM module can be unloaded while guest_memfd folios are being evicted, causing a Use-After-Free crash when calling a_ops->free_folio().
--
commit dd2a52e3b94932f45c23fd6812c93b476a753c85
Author: Sean Christopherson <seanjc@google.com>
KVM: Rework .gmem_invalidate() into .gmem_free_folio()
Rename .gmem_invalidate() to .gmem_free_folio() as the hook is called when
a folio is freed. Drop guest_memfd's trampoline and wire up .free_folio()
directly to the arch callback.
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 86690683b2fe3..1618acc3ca647 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
> @@ -523,23 +523,12 @@ static int kvm_gmem_error_folio(struct address_space *mapping, struct folio *fol
> return MF_DELAYED;
> }
>
> -#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> -static void kvm_gmem_free_folio(struct folio *folio)
> -{
> - struct page *page = folio_page(folio, 0);
> - kvm_pfn_t pfn = page_to_pfn(page);
> - int order = folio_order(folio);
> -
> - kvm_arch_gmem_invalidate(pfn, pfn + (1ul << order));
> -}
> -#endif
> -
> static const struct address_space_operations kvm_gmem_aops = {
> .dirty_folio = noop_dirty_folio,
> .migrate_folio = kvm_gmem_migrate_folio,
> .error_remove_folio = kvm_gmem_error_folio,
> #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> - .free_folio = kvm_gmem_free_folio,
> + .free_folio = kvm_arch_gmem_free_folio,
[Severity: High]
This is a pre-existing issue, but can this lead to an execution-after-free
crash during module unload?
When a user closes all KVM-related file descriptors, __fput() drops the
module reference via fops_put(file->f_op) before it calls dput(). The
dput() call subsequently drops the inode reference and triggers page cache
eviction.
Because kvm_gmem_fs lacks .owner = THIS_MODULE, the superblock and
inodes do not independently pin the KVM module in memory.
If an administrator unloads the KVM module after fops_put() but before
eviction completes, does the mapping->a_ops->free_folio() call in the page
cache eviction path attempt to execute unmapped memory?
> #endif
> };
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625222229.3367197-1-seanjc@google.com?part=4
next prev parent reply other threads:[~2026-06-25 22:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 22:22 [PATCH 0/7] KVM: SEV: Fix RMP #PF due freeing in-use VMSA Sean Christopherson
2026-06-25 22:22 ` [PATCH 1/7] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests Sean Christopherson
2026-06-25 22:22 ` [PATCH 2/7] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper Sean Christopherson
2026-06-25 22:22 ` [PATCH 3/7] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable Sean Christopherson
2026-06-25 22:22 ` [PATCH 4/7] KVM: Rework .gmem_invalidate() into .gmem_free_folio() Sean Christopherson
2026-06-25 22:39 ` sashiko-bot [this message]
2026-06-25 22:22 ` [PATCH 5/7] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Sean Christopherson
2026-06-25 22:45 ` sashiko-bot
2026-06-25 23:28 ` Sean Christopherson
2026-06-25 22:22 ` [PATCH 6/7] KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=y Sean Christopherson
2026-06-25 22:22 ` [PATCH 7/7] KVM: SEV: Mark vCPU has having guest-provided VMSA even if its invalid 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=20260625223920.6C7511F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.com \
/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.