Created attachment 6870 [details] Testcase When _IO_flush_all_lockp is called from _IO_cleanup it doesn't do any locking on _IO_list_all, which races with fopen/fclose from other threads. This can result in heap corruption.
I have two related issues open on the Austin Group bug tracker: http://austingroupbugs.net/view.php?id=610 http://austingroupbugs.net/view.php?id=611 Unfortunately, I believe the current glibc behavior of not performing appropriate locking is intentional, so that exit works even when locks would/should block exit. This is contrary to the requirements of the standard and harmful to applications that have expectations on the atomicity/integrity of stdio operations performed under lock.
Doesn't seem any recent progress on the issues.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 19f82f358670f4b80533156b9edbf81223358bf9 (commit) from 91e7cf982d0104f0e71770f5ae8e3faf352dea9f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=19f82f358670f4b80533156b9edbf81223358bf9 commit 19f82f358670f4b80533156b9edbf81223358bf9 Author: Andreas Schwab <schwab@suse.de> Date: Mon Aug 21 16:07:29 2017 +0200 Always do locking when iterating over list of streams (bug 15142) _IO_list_all should only be traversed while locking list_all_lock. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 8 +++++++ libio/genops.c | 60 ++++++++++++++++--------------------------------------- 2 files changed, 26 insertions(+), 42 deletions(-)
*** Bug 30510 has been marked as a duplicate of this bug. ***