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) <[email protected]> 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. > 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-7d9781ed5...@kernel.org?part=16
