[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230712024804.GH4163@brightrain.aerifal.cx>
Date: Tue, 11 Jul 2023 22:48:04 -0400
From: Rich Felker <dalias@...c.org>
To: "Appelmans, Madeleine" <madelea@...zon.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Difference in pthread behavior between glibc and musl
On Tue, Jul 11, 2023 at 07:19:50PM +0000, Appelmans, Madeleine wrote:
> Hello,
>
> There seems to be a difference in pthread behavior when compiling
> with glibc and using the musl-gcc wrapper. The attached snippet of
> code creates a destructor attribute which deletes a pthread key. The
> code never actually creates the pthread key. This code segfaults
> when compiled using musl-gcc, and does not segfault when compiled
> with gcc.
>
> Best guess at what is going on: When creating a pthread key, musl
> initializes a field called
> tsd<https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_key_create.c#n37>.
> When deleting a key, musl assumes that initialization has been done,
> and dereferences tsd without checking that it exists: see
> here<https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_key_create.c#n65>.
> This dereference may be the source of the segfault.
This is completely expected; the behavior is undefined because you
passed to pthread_key_delete a value which was not acquired via
pthread_key_create.
If it happens not to crash on glibc, that doesn't mean it's okay to do
it. It will end up deleting whatever key happens to correspond to the
zero-initialized pthread_key_t object, which may be a key that was
allocated for use by some other part of the program when it called
pthread_key_create. (In other words, you have a type of double-free or
use-after-free bug.) Your program logic must ensure you refrain from
doing that.
Rich
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.
