diff options
| author | Adhemerval Zanella <adhemerval.zanella@linaro.org> | 2025-04-24 12:27:44 -0300 |
|---|---|---|
| committer | Adhemerval Zanella <adhemerval.zanella@linaro.org> | 2025-04-28 10:13:46 -0300 |
| commit | 0c3425942374e72c3bcac28b2578117d36b0f9df (patch) | |
| tree | 34cc4753eec69109e6ff938b7fd1f5d3cf9b12c2 /sysdeps/unix/sysv/linux/clone-internal.c | |
| parent | 4c966c078036abe0e36bd86c9eaeb4501e552977 (diff) | |
| download | glibc-0c3425942374e72c3bcac28b2578117d36b0f9df.zip glibc-0c3425942374e72c3bcac28b2578117d36b0f9df.tar.gz glibc-0c3425942374e72c3bcac28b2578117d36b0f9df.tar.bz2 | |
nptl: Fix pthread_getattr_np when modules with execstack are allowed (BZ 32897)
The BZ 32653 fix (12a497c716f0a06be5946cabb8c3ec22a079771e) kept the
stack pointer zeroing from make_main_stack_executable on
_dl_make_stack_executable. However, previously the 'stack_endp'
pointed to temporary variable created before the call of
_dl_map_object_from_fd; while now we use the __libc_stack_end
directly.
Since pthread_getattr_np relies on correct __libc_stack_end, if
_dl_make_stack_executable is called (for instance, when
glibc.rtld.execstack=2 is set) __libc_stack_end will be set to zero,
and the call will always fail.
The __libc_stack_end zero was used a mitigation hardening, but since
52a01100ad011293197637e42b5be1a479a2f4ae it is used solely on
pthread_getattr_np code. So there is no point in zeroing anymore.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Sam James <sam@gentoo.org>
Diffstat (limited to 'sysdeps/unix/sysv/linux/clone-internal.c')
0 files changed, 0 insertions, 0 deletions