]> git.ipfire.org Git - thirdparty/glibc.git/commit
stdlib: Fix data race in __run_exit_handlers [BZ #27749]
authorVitaly Buka <vitalybuka@google.com>
Mon, 26 Apr 2021 19:27:29 +0000 (12:27 -0700)
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>
Fri, 14 May 2021 14:36:40 +0000 (11:36 -0300)
commit16adc58e73f364f75e58e04bac914aac64fd0613
tree7b39f6c41a35c7cd35f07ea5c19fbeb17df93d70
parent7a7bcddeefdb60d0f333a60c6cff15974bf8f66b
stdlib: Fix data race in __run_exit_handlers [BZ #27749]

Keep __exit_funcs_lock almost all the time and unlock it only to execute
callbacks. This fixed two issues.

1. f->func.cxa was modified outside the lock with rare data race like:
thread 0: __run_exit_handlers unlock __exit_funcs_lock
thread 1: __internal_atexit locks __exit_funcs_lock
thread 0: f->flavor = ef_free;
thread 1: sees ef_free and use it as new
thread 1: new->func.cxa.fn = (void (*) (void *, int)) func;
thread 1: new->func.cxa.arg = arg;
thread 1: new->flavor = ef_cxa;
thread 0: cxafct = f->func.cxa.fn;  // it's wrong fn!
thread 0: cxafct (f->func.cxa.arg, status);  // it's wrong arg!
thread 0: goto restart;
thread 0: call the same exit_function again as it's ef_cxa

2. Don't unlock in main while loop after *listp = cur->next. If *listp
   is NULL and __exit_funcs_done is false another thread may fail in
   __new_exitfn on assert (l != NULL):
 thread 0: *listp = cur->next;  // It can be the last: *listp = NULL.
 thread 0: __libc_lock_unlock
 thread 1: __libc_lock_lock in __on_exit
 thread 1: __new_exitfn
 thread 1: if (__exit_funcs_done)  // false: thread 0 isn't there yet.
 thread 1: l = *listp
 thread 1: moves one and crashes on assert (l != NULL);

The test needs multiple iterations to consistently fail without the fix.

Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=27749

Checked on x86_64-linux-gnu.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
stdlib/Makefile
stdlib/exit.c
stdlib/test-cxa_atexit-race2.c [new file with mode: 0644]