Hello,
I recently came across a memory corruption
in the member "tsd" of struct pthread
in a scenario where a pthread mutex
is intentionally held during fork().
I experienced this using the lastest
release 1.1.23.
I found that during fork musl resets
self->robust_list.pending and self->robust_list.off,
but not the robust_list.head. The stale
pointer to the previously held and reset
mutex turned out to be the cause for
the following corruption.
I therefore suggest to also reset the
list head on fork as such:
--- a/src/process/fork.c.orig
2019-09-23 11:41:01.381626360 +0200
+++ b/src/process/fork.c
2019-09-23 11:41:26.657819473 +0200
@@ -27,6 +27,7 @@
self->tid = __syscall(SYS_gettid);
self->robust_list.off = 0;
self->robust_list.pending = 0;
+
self->robust_list.head = &self->robust_list.head;
self->next = self->prev = self;
__thread_list_lock = 0;
libc.threads_minus_1 = 0;
This resolves the issue.
I am very well aware of the fact that
aquiring a mutex during fork and re-initializing
in the child appears to result in undefined
behaviour (as of pthread_mutex_init(3posix))
or to be controversial at least.
However I believe that it should't
result in a memory corruption as a result.
To reproduce I wrote a small example
which triggers and shows the curruption.
It also contains a description of the
program flow and memory corruption.
Please find it attached to this mail.
Please note that the routine to print
the robust_list is hacked using hardcoded
offsets which are aimed at my 32-Bit
platform.
Best regards,
Daniel
--
AVM Audiovisuelles Marketing und Computersysteme GmbH
Alt-Moabit 95, 10559 Berlin
HRB 23075 AG Charlottenburg
Geschäftsführer: Johannes Nill