Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jan 2024 15:27:37 -0800
From: enh <>
Cc: jvoisin <>
Subject: Re: Protect pthreads' mutexes against use-after-destroy

On Tue, Jan 9, 2024 at 11:07 AM Rich Felker <> wrote:
> On Tue, Jan 09, 2024 at 03:37:17PM +0100, jvoisin wrote:
> > Ohai,
> >
> > as discussed on irc, Android's bionic has a check to prevent
> > use-after-destroy on phtread mutexes
> > (,
> > and musl doesn't.
> >
> > While odds are that this is a super-duper common bug, it would still be
> > nice to have this kind of protection, since it's cheap, and would
> > prevent/make it easy to diagnose weird states.
> >
> > Is this something that should/could be implemented?
> >
> > o/
> I think you meant that the odds are it's not common.

it was common enough (and hard enough to debug) that we added this
"best effort" error detection to bionic :-)

(the other "surely no-one actually does that?" mistake i can think of
in this area is that a surprising number of people seem to think that
`pthread_mutex_lock(NULL)` means something. i'm still not sure _what_
they think it means!)

> There's already
> enough complexity in the code paths for supporting all the different
> mutex types that my leaning would be, if we do any hardening for
> use-after-destroy, that it should probably just take the form of
> putting the object in a state that will naturally deadlock or error
> rather than adding extra checks to every path where it's used.

yeah, the _other_ reason we have the abort is that we've struggled
over the years to make it clear to the _callers_ that -- just because
you crash/hang in libc -- it's the _caller's_ bug. explicitly saying
so helps. (though we still get a decent number of people who don't
read/don't understand.)

> If OTOH we do want it to actually trap in all cases where it's used
> after destroy, the simplest way to achieve that is probably to set it
> up as a non-robust non-PI recursive or errorchecking mutex with
> invalid prev/next pointers and owner of 0x3fffffff. Then the only
> place that would actually have to have an explicit trap is trylock in
> the code path:
>         if (own == 0x3fffffff) return ENOTRECOVERABLE;
> where it could trap if type isn't robust. The unlock code path would
> trap on accessing invalid prev/next pointers.
> 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.