diff options
author | 2025-03-06 16:12:21 -0500 | |
---|---|---|
committer | 2025-03-06 22:26:49 +0100 | |
commit | fd881d0a085fc54354414aed990ccf05f282ba53 (patch) | |
tree | 007e29a23c223251468ff84d580ab4b6b2936018 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | Merge branch 'sched/urgent' into sched/core, to pick up dependent commits (diff) | |
download | wireguard-linux-fd881d0a085fc54354414aed990ccf05f282ba53.tar.xz wireguard-linux-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 <mjeanson@efficios.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250306211223.109455-1-mjeanson@efficios.com
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions