diff options
author | Szabolcs Nagy <szabolcs.nagy@arm.com> | 2021-04-07 12:45:53 +0100 |
---|---|---|
committer | Szabolcs Nagy <szabolcs.nagy@arm.com> | 2021-04-12 14:28:07 +0100 |
commit | 8d4d77f6c848538cfb9e5ad0a14825e7ae4a1657 (patch) | |
tree | cdd1b53b09d6d84607d7be04196bbe2e1f8ae062 /sysdeps/alpha/fpu/s_copysignf.c | |
parent | 9f1bed18f9466ac886addb2f79d8e4c52fb65eb5 (diff) | |
download | glibc-8d4d77f6c848538cfb9e5ad0a14825e7ae4a1657.tar.gz glibc-8d4d77f6c848538cfb9e5ad0a14825e7ae4a1657.tar.xz glibc-8d4d77f6c848538cfb9e5ad0a14825e7ae4a1657.zip |
arm: Fix an incorrect check in ____longjmp_chk [BZ #27709]
An incorrect check in __longjmp_chk could fail on valid code causing FAIL: debug/tst-longjmp_chk2 The original check was altstack_sp + altstack_size - setjmp_sp > altstack_size i.e. sp at setjmp was outside of the altstack range. Here we know that longjmp is called from a signal handler on the altstack (SS_ONSTACK), and that it jumps in the wrong direction (sp decreases), so the check wants to ensure the jump goes to another stack. The check is wrong when altstack_sp == setjmp_sp which can happen when the altstack is a local buffer in the function that calls setjmp, so the patch allows == too. This fixes bug 27709. Note that the generic __longjmp_chk check seems to be different. (it checks if longjmp was on the altstack but does not check setjmp, so it would not catch incorrect longjmp use within the signal handler).
Diffstat (limited to 'sysdeps/alpha/fpu/s_copysignf.c')
0 files changed, 0 insertions, 0 deletions