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 <[email protected]> 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/[email protected]?part=4
