aboutsummaryrefslogtreecommitdiffstats
path: root/rust/helpers/task.c
diff options
context:
space:
mode:
authorFlorent Revest <[email protected]>2025-05-07 13:09:57 +0000
committerAndrew Morton <[email protected]>2025-05-21 05:49:38 +0000
commit0f518255bde881d2a2605bbc080b438b532b6ab2 (patch)
tree1b49636342a09f11b1ff0b95450927fb75a13828 /rust/helpers/task.c
parentmm: mmap: map MAP_STACK to VM_NOHUGEPAGE only if THP is enabled (diff)
downloadkernel-0f518255bde881d2a2605bbc080b438b532b6ab2.tar.gz
kernel-0f518255bde881d2a2605bbc080b438b532b6ab2.zip
mm: fix VM_UFFD_MINOR == VM_SHADOW_STACK on USERFAULTFD=y && ARM64_GCS=y
On configs with CONFIG_ARM64_GCS=y, VM_SHADOW_STACK is bit 38. On configs with CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y (selected by CONFIG_ARM64 when CONFIG_USERFAULTFD=y), VM_UFFD_MINOR is _also_ bit 38. This bit being shared by two different VMA flags could lead to all sorts of unintended behaviors. Presumably, a process could maybe call into userfaultfd in a way that disables the shadow stack vma flag. I can't think of any attack where this would help (presumably, if an attacker tries to disable shadow stacks, they are trying to hijack control flow so can't arbitrarily call into userfaultfd yet anyway) but this still feels somewhat scary. Link: https://lkml.kernel.org/r/[email protected] Fixes: ae80e1629aea ("mm: Define VM_SHADOW_STACK for arm64 when we support GCS") Signed-off-by: Florent Revest <[email protected]> Reviewed-by: Mark Brown <[email protected]> Cc: Borislav Betkov <[email protected]> Cc: Brendan Jackman <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Florent Revest <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thiago Jung Bauermann <[email protected]> Cc: Thomas Gleinxer <[email protected]> Cc: Will Deacon <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Diffstat (limited to 'rust/helpers/task.c')
0 files changed, 0 insertions, 0 deletions