mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Gabriel Ravier <>
Cc:, "Appelmans, Madeleine" <>
Subject: Re: [musl] Difference in pthread behavior between glibc and musl
Date: Wed, 12 Jul 2023 21:50:46 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 13, 2023 at 03:00:55AM +0200, Gabriel Ravier wrote:
> On 7/12/23 04:48, Rich Felker wrote:
> >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<>.
> >>When deleting a key, musl assumes that initialization has been done,
> >>and dereferences tsd without checking that it exists: see
> >>here<>.
> >>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
> Hmmm, this does indeed seem to be the case ever since
> SUSv4/XPG7/POSIX.1-2008 removed the EINVAL error from the
> specification of pthread_key_delete, but the requirement to detect
> this error is present in SUSv3/XPG6/POSIX.1-2001 (up to and
> including the 2004 edition). so if you want musl to be able to say
> it conforms to that standard, it would have to implement this, which
> after a quick look at musl's source code w.r.t. pthread keys doesn't
> seem particularly burdensome.

There was never a requirement to detect UAF/DF type errors. There was
a requirement ("shall fail"), *if the implementation does detect it*,
to fail with EINVAL. This was nonsensical because there was no
requirement to do the detection (and in general the detection is
impossible; that's the nature of UAF/DF) so the confusing text was
fixed. But there was no change in the actual requirement.

> Personally I'd be in favor of having this detection occur regardless
> of whether musl aims for conformance to older standards given that
> POSIX still now explicitly recommends it even in the standards where
> it is not mandatory anymore, which is something I've usually seen

It is not "explicitly recommended", and it's against best practices to
return an error rather than trapping on UB.


  reply	other threads:[~2023-07-13  1:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 19:19 Appelmans, Madeleine
2023-07-11 19:42 ` Markus Wichmann
2023-07-12  2:48 ` Rich Felker
2023-07-13  1:00   ` Gabriel Ravier
2023-07-13  1:50     ` Rich Felker [this message]
2023-07-13  2:02       ` Gabriel Ravier
2023-07-13 16:27         ` Markus Wichmann
2023-07-13 18:49           ` Gabriel Ravier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).