Re: [PATCH v2 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the x86-specific bottom-up mmap fallback path silently discards VMA flags, bypassing the shadow stack guard gap allocation.
--

--- Patch [4]: [PATCH v2 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t ---
commit 00b351f4aaa23a000490d96bd47f04d6f2e0f5d1
Author: Lorenzo Stoakes <ljs@kernel.org>

mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t

This commit updates generic_get_unmapped_area() and
generic_get_unmapped_area_topdown() to accept vma_flags_t instead of
vm_flags_t. It also updates stack_guard_placement() to use the new type.
The architecture-specific wrappers are retained but use legacy_to_vma_flags()
for compatibility.

> diff --git a/mm/mmap.c b/mm/mmap.c
> index 4a88b2a233f7f..39d33f3a55c2e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c

[ ... ]

> @@ -807,7 +807,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
>  			       unsigned long flags, vm_flags_t vm_flags)
>  {
>  	return generic_get_unmapped_area_topdown(filp, addr, len, pgoff, flags,
> -						 vm_flags);
> +						 legacy_to_vma_flags(vm_flags));

[Severity: High]
This isn't a bug introduced by this patch, but the x86-specific bottom-up mmap
fallback path silently discards VMA flags, bypassing the shadow stack guard
gap allocation.

Is it possible for an attacker to intentionally exhaust the top-down allocation
space (e.g., via high stack limits) to force the shadow stack allocation (using
the map_shadow_stack syscall) into the fallback bottom-up path in
arch_get_unmapped_area_topdown()?

In arch/x86/kernel/sys_x86_64.c, the fallback path looks like this:

bottomup:
	/*
	 * A failed mmap() very likely causes application failure,
	 * so fall back to the bottom-up function here. This scenario
	 * can happen with large stack limits and large mmap()
	 * allocations.
	 */
	return arch_get_unmapped_area(filp, addr0, len, pgoff, flags, 0);

By passing 0 for vm_flags, does this completely drop the VM_SHADOW_STACK flag
before the guard gap allocation logic checks for it?

Could this bypass allow shadow stacks to be allocated immediately adjacent to
other mappings, meaning if a shadow stack overflows, it corrupts adjacent data
instead of hitting a guard page?

>  }
>  #endif
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org?part=4