From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1179 invoked from network); 13 Jul 2023 01:51:02 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 13 Jul 2023 01:51:02 -0000 Received: (qmail 14004 invoked by uid 550); 13 Jul 2023 01:50:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13969 invoked from network); 13 Jul 2023 01:50:58 -0000 Date: Wed, 12 Jul 2023 21:50:46 -0400 From: Rich Felker To: Gabriel Ravier Cc: musl@lists.openwall.com, "Appelmans, Madeleine" Message-ID: <20230713015046.GI4163@brightrain.aerifal.cx> References: <20230712024804.GH4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Difference in pthread behavior between glibc and musl 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. Rich