diff options
| author | Florent Revest <[email protected]> | 2025-05-07 13:09:57 +0000 |
|---|---|---|
| committer | Andrew Morton <[email protected]> | 2025-05-21 05:49:38 +0000 |
| commit | 0f518255bde881d2a2605bbc080b438b532b6ab2 (patch) | |
| tree | 1b49636342a09f11b1ff0b95450927fb75a13828 /rust/helpers/task.c | |
| parent | mm: mmap: map MAP_STACK to VM_NOHUGEPAGE only if THP is enabled (diff) | |
| download | kernel-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
