Re: [PATCH v2 16/40] mm/vma: only allow mmap to clear VMA_MAYWRITE_BIT if kernel-owned
From: sashiko-bot@kernel.org
Date: 2026-09-14 19:14:09
Also in:
bpf, dri-devel, kvm, kvmarm, linux-perf-users, linux-rdma, linux-s390, linux-scsi, selinux
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [Critical] VMA flags and `pgoff` modifications performed by `mmap_action_prepare()` are lost in `call_mmap_prepare()`, resulting in missing `VM_MIXEDMAP` / `VM_PFNMAP` flags on the final VMA. -- commit 7ddd38612e8ff73188b344ec633bfe65678e0dce Author: Lorenzo Stoakes (ARM) [off-list ref] mm/vma: only allow mmap to clear VMA_MAYWRITE_BIT if kernel-owned For ordinary files the only way the VMA_MAYWRITE_BIT flag is cleared is if the underlying file is itself read-only. [ ... ] As all drivers which clear VMA_MAYWRITE_BIT establish kernel-owned mappings, no functional change is intended.
quoted hunk ↗ jump to hunk
diff --git a/mm/vma.c b/mm/vma.c index 2648fb0e19959..d71ec51255b18 100644 --- a/mm/vma.c +++ b/mm/vma.c@@ -2795,6 +2795,11 @@ static int mmap_validate(unsigned long prev_start, if (WARN_ON_ONCE(!was_maywrite && is_maywrite)) return -EINVAL; + /* Only kernel-owned mappings may clear VMA_MAYWRITE_BIT. */ + if (!vma_flags_is_kernel_owned(curr_flags) && + WARN_ON_ONCE(was_maywrite && !is_maywrite)) + return -EINVAL; + return mmap_validate_vma_flags(curr_flags); }
[Severity: Critical]
This isn't a bug introduced by this patch, but while reviewing mm/vma.c,
I noticed a potential issue in call_mmap_prepare():
mm/vma.c:call_mmap_prepare() {
/* Update fields permitted to be changed. */
map->pgoff = desc->pgoff;
if (desc->vm_file != map->vm_file)
map->vm_file = desc->vm_file;
map->vma_flags = desc->vma_flags;
map->page_prot = desc->page_prot;
/* User-defined fields. */
map->vm_ops = desc->vm_ops;
map->vm_private_data = desc->private_data;
/* It's invalid for mmap_prepare hooks to clear vm_ops. */
if (!desc->vm_ops)
return -EINVAL;
err = call_action_prepare(map, desc);
if (err)
return err;
}
Are the VMA flags and pgoff modifications performed by call_action_prepare()
lost here? Since map->vma_flags and map->pgoff are initialized from desc
before calling call_action_prepare(), the updated fields in desc are never
synchronized back to map.
Could this lead to missing VM_MIXEDMAP or VM_PFNMAP flags on the final VMA?
If unprivileged userspace calls mmap() on a driver using remap_pfn_range(),
might the core memory management subsystem treat hardware/PFN mapped pages
as normal anonymous or file-backed RAM pages?
This could result in the kernel attempting to manage page reference counts on
arbitrary physical I/O memory PFNs when the VMA is later unmapped or
accessed, potentially leading to immediate crashes or silent corruption.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@kernel.org?part=16