diff options
| author | Michael Jeanson <[email protected]> | 2025-03-06 21:12:21 +0000 |
|---|---|---|
| committer | Ingo Molnar <[email protected]> | 2025-03-06 21:26:49 +0000 |
| commit | fd881d0a085fc54354414aed990ccf05f282ba53 (patch) | |
| tree | 007e29a23c223251468ff84d580ab4b6b2936018 /lib/dump_stack.c | |
| parent | Merge branch 'sched/urgent' into sched/core, to pick up dependent commits (diff) | |
| download | kernel-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
