From: sashiko-bot@kernel.org
To: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: dri-devel@lists.freedesktop.org, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH v2 1/6] mm: export vmf_insert_pfn_prot_mkwrite(), change variants to inline
Date: Tue, 04 Aug 2026 12:20:41 +0000 [thread overview]
Message-ID: <20260804122042.4F3601F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260804120529.1730187-2-pbonzini@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The global shared zero page can be mapped as writable by insert_pfn, leading to memory corruption.
--
--- Patch [1]: [PATCH v2 1/6] mm: export vmf_insert_pfn_prot_mkwrite(), change variants to inline ---
commit 010e09346cc93d215af7040a0cfe7fd891a1bd7d
Author: Paolo Bonzini <pbonzini@redhat.com>
mm: export vmf_insert_pfn_prot_mkwrite(), change variants to inline
This commit introduces vmf_insert_pfn_prot_mkwrite() and
vmf_insert_pfn_mkwrite() to allow drivers to install writable PTEs during
faults when a mapping is under write notification. It refactors the existing
vmf_insert_pfn() family of functions into inline wrappers around this new,
more flexible variant.
> diff --git a/mm/memory.c b/mm/memory.c
> index 6637c5b13c9ba..786b114d9921a 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
[ ... ]
> -vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
> - unsigned long pfn, pgprot_t pgprot)
> +vm_fault_t vmf_insert_pfn_prot_mkwrite(struct vm_area_struct *vma,
> + unsigned long addr, unsigned long pfn, pgprot_t pgprot,
> + bool mkwrite)
> {
[ ... ]
> pfnmap_setup_cachemode_pfn(pfn, &pgprot);
>
> - return insert_pfn(vma, addr, pfn, pgprot, false);
> -}
> -EXPORT_SYMBOL(vmf_insert_pfn_prot);
> -
> -/**
> - * vmf_insert_pfn - insert single pfn into user vma
[ ... ]
> + return insert_pfn(vma, addr, pfn, pgprot, mkwrite);
> }
> -EXPORT_SYMBOL(vmf_insert_pfn);
> +EXPORT_SYMBOL(vmf_insert_pfn_prot_mkwrite);
[Severity: Critical]
This is a pre-existing issue, but by allowing mkwrite to be passed directly
through to insert_pfn(), can this result in the global shared zero page being
mapped writable?
If a driver maps the zero page via vmf_insert_pfn_mkwrite(..., true) into a
shared writable VM_PFNMAP mapping, insert_pfn() in mm/memory.c handles the
new entry like this:
/* Ok, finally just insert the thing.. */
entry = pte_mkspecial(pfn_pte(pfn, prot));
if (mkwrite) {
entry = pte_mkyoung(entry);
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
}
Because there is no check verifying if the passed PFN is the zero page,
maybe_mkwrite() will explicitly make the PTE writable, bypassing the zero
page protections ordinarily afforded by vm_mixed_ok().
If the global zero page becomes writable, unprivileged userspace could write
to it, which would cause memory corruption across the system for any process
reading uninitialized memory. Should we add a defense in insert_pfn() to
explicitly reject or write-protect the zero page when mkwrite is true?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804120529.1730187-1-pbonzini@redhat.com?part=1
next prev parent reply other threads:[~2026-08-04 12:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 12:05 [PATCH v2 0/6] mm, drm: fix interaction of .pfn_mkwrite() with fixup_user_fault() Paolo Bonzini
2026-08-04 12:05 ` [PATCH v2 1/6] mm: export vmf_insert_pfn_prot_mkwrite(), change variants to inline Paolo Bonzini
2026-08-04 12:20 ` sashiko-bot [this message]
2026-08-10 19:04 ` David Hildenbrand (Arm)
2026-08-04 12:05 ` [PATCH v2 2/6] drm/shmem_helper: use vmf_insert_pfn_mkwrite() Paolo Bonzini
2026-08-04 12:30 ` sashiko-bot
2026-08-04 14:15 ` Boris Brezillon
2026-08-04 14:18 ` Boris Brezillon
2026-08-04 14:34 ` Paolo Bonzini
2026-08-04 14:42 ` Boris Brezillon
2026-08-05 6:08 ` Paolo Bonzini
2026-08-05 8:34 ` Boris Brezillon
2026-08-04 12:05 ` [PATCH v2 3/6] drm/ttm, drm/vmwgfx: directly create writable PTEs when mkwrite is in use Paolo Bonzini
2026-08-04 12:21 ` sashiko-bot
2026-08-04 12:47 ` Paolo Bonzini
2026-08-06 23:32 ` Peter Xu
2026-08-10 10:01 ` Christian König
2026-08-10 10:04 ` Paolo Bonzini
2026-08-04 12:05 ` [PATCH v2 4/6] kvm: apply VM_READ/VM_WRITE checks to all VMA types Paolo Bonzini
2026-08-04 12:23 ` sashiko-bot
2026-08-04 12:44 ` Paolo Bonzini
2026-08-04 21:15 ` Sean Christopherson
2026-08-04 12:05 ` [PATCH v2 5/6] mm: pull writability check to follow_pfnmap_start() Paolo Bonzini
2026-08-04 12:14 ` sashiko-bot
2026-08-04 12:05 ` [PATCH v2 6/6] kvm: return -EFAULT for writes to !VM_WRITE IO mappings Paolo Bonzini
2026-08-04 12:14 ` sashiko-bot
2026-08-04 21:08 ` 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=20260804122042.4F3601F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.