aboutsummaryrefslogtreecommitdiffstats
path: root/lib/dump_stack.c
diff options
context:
space:
mode:
authorMichael Jeanson <[email protected]>2025-03-06 21:12:21 +0000
committerIngo Molnar <[email protected]>2025-03-06 21:26:49 +0000
commitfd881d0a085fc54354414aed990ccf05f282ba53 (patch)
tree007e29a23c223251468ff84d580ab4b6b2936018 /lib/dump_stack.c
parentMerge branch 'sched/urgent' into sched/core, to pick up dependent commits (diff)
downloadkernel-fd881d0a085fc54354414aed990ccf05f282ba53.tar.gz
kernel-fd881d0a085fc54354414aed990ccf05f282ba53.zip
rseq: Fix segfault on registration when rseq_cs is non-zero
The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation. Signed-off-by: Michael Jeanson <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'lib/dump_stack.c')
0 files changed, 0 insertions, 0 deletions