Re: [PATCH v2 05/40] mm/vma: ensure mmap_prepare doesn't set actions on a mergeable vma

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] State modification applied to `desc->vma_flags` during action preparation is not propagated back to `map->vma_flags`, resulting in incorrect VMA merging and the silent loss of critical flags like `VM_PFNMAP` and `VM_IO`.
--

commit 31f214221abd5db93fe1f46874d29ea3c59a0cc7
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

mm/vma: ensure mmap_prepare doesn't set actions on a mergeable vma

When a user requests an mmap_action be performed in mmap_prepare, this
involves populating the VMA range with data. This patch asserts that no
future mmap action is performed on a mergeable VMA upon mmap_prepare
validation.

> diff --git a/mm/vma.c b/mm/vma.c
> index 626a18c08a269..2648fb0e19959 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -2809,6 +2809,15 @@ static int mmap_validate(unsigned long prev_start,
>  int mmap_prepare_validate(const struct vm_area_desc *prev_desc,
>  			  const struct vm_area_desc *desc)
>  {
> +	/*
> +	 * It is not valid to execute mmap actions for VMAs which can be merged,
> +	 * as any such merge would leave portions of the mapping incorrectly
> +	 * unmapped.
> +	 */
> +	if (vma_flags_can_merge(&desc->vma_flags) &&
> +	    WARN_ON_ONCE(desc->action.type != MMAP_NOTHING))
> +		return -EINVAL;
> +

[Severity: Critical]
Does this check actually prevent the merge? Looking at call_mmap_prepare(),
map->vma_flags is copied from desc->vma_flags before call_action_prepare()
is called:

mm/vma.c:call_mmap_prepare() {
	...
	map->vma_flags = desc->vma_flags;
	...
	err = call_action_prepare(map, desc);
	if (err)
		return err;

	err = mmap_prepare_validate(&prev_desc, desc);
	...
}

If call_action_prepare() mutates desc->vma_flags to include action-specific
unmergeable flags, vma_flags_can_merge(&desc->vma_flags) will be false here,
allowing the validation to pass. However, these changes don't appear to be
synchronized back to map->vma_flags.

Could this cause the actual VMA operations to operate on the stale and
mergeable map->vma_flags?

If a VMA lacks VM_PFNMAP or VM_IO but contains PFN-mapped pages, could this
lead to memory corruption if kernel mechanisms assume the pages are normal
memory and call put_page() on raw PFNs?

>  	return mmap_validate(prev_desc->start, desc->start,
>  			     &prev_desc->vma_flags, &desc->vma_flags);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@kernel.org?part=5