Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Jun 2019 01:42:25 +0200
From: Bruno Haible <bruno@...sp.org>
To: musl@...ts.openwall.com
Subject: TLS and TSS APIs have race conditions in musl

Hi,

The attached test programs exercise the <pthread.h> thread-local storage (TLS)
API and the <threads.h> thread-specific storage (TSS) API in libc.

On Alpine Linux 3.7 and 2.9, these test programs, when run, produce this output:

$ ./test-tls
Starting test_tls ... OK
Starting test_tls_dtorcheck1 ... OK
Starting test_tls_dtorcheck2 ... OK
Starting test_tls_racecheck ...Aborted
$ ./test-tss
Starting test_tss ... OK
Starting test_tss_dtorcheck1 ... OK
Starting test_tss_dtorcheck2 ... OK
Starting test_tss_racecheck ...Aborted

The expected output - like seen on glibc, macOS, FreeBSD, NetBSD, OpenBSD,
AIX, HP-UX, IRIX, Solaris, Haiku, and Cygwin - is

$ ./test-tls
Starting test_tls ... OK
Starting test_tls_dtorcheck1 ... OK
Starting test_tls_dtorcheck2 ... OK
Starting test_tls_racecheck ... OK

test_tls_racecheck provokes races by doing many pthread_key_create and
pthread_key_delete calls in parallel threads.

test_tss_racecheck provokes races by doing many tss_create and tss_delete
calls in parallel threads.

I would guess that it is a musl libc bug.


View attachment "test-tls.c" of type "text/x-csrc" (15405 bytes)

View attachment "test-tss.c" of type "text/x-csrc" (15892 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.