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.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, 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 32197 invoked from network); 13 Jul 2023 01:01:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 13 Jul 2023 01:01:14 -0000 Received: (qmail 17928 invoked by uid 550); 13 Jul 2023 01:01:11 -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 17896 invoked from network); 13 Jul 2023 01:01:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689210058; x=1691802058; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=nAINrBuDfoH6dJpY7Ad8zLdXyZctkhfVSq/PAdHFf3A=; b=gKjzP28x8fqVTIUxn9+kFLSwyTZilW17Dg8+ndCVXPqer3yXvltUMNmDzqEDjrm100 vIjKD3FwCbUP+7WT4iHMeDvlnliUs4OaEPHqaVOzFGhyal+WO6d1Xr6HLdkLOp6+mVtE pjDSMDhGhBRa5TIOx4n6gZhwwFUzdNAmK2wQ4AX6teqirHyqPHofj+VA4fjBNTbeo3uJ jzo5LjKAjlcE3b5/8fcXqKmohgjLNi9VH6D0VOJd75g68RpPnpkOOVkm0gBQHxiRttln 1jsABKVIEhRd3RI86POzV7LuXDR11RTtDRPC0PV04Wd0IPf8PAdkUK2cJkJtilscluaM IN1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689210058; x=1691802058; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nAINrBuDfoH6dJpY7Ad8zLdXyZctkhfVSq/PAdHFf3A=; b=T/QqMVt+Z0mhN98UW8WX4sl2EkVVngPvrSlC7S1BkVRKYyX7fDQek/HAF8+PcfnVt6 gRRf/UFarEfVttP+3l7S+dQhBYuRztYo6RyMN3xlIF6yS/I/ER/b8MzIYnfKvoQMDPFy 5cD1njVl/kDgiRtpWXSVD44u5BcMBdmAIQ0HZiQndUV5n8SYzf6i05E73Kv6Cve+4eRh QD+60sClQexc7quyJVp/Fs6REoY+l4JFcavMbMhhlaYOPUE/NdjJNeFEZ5OwIp4pHQ81 5YsOuO09va/4sgNHGaYRNBUK2nCNq4XhnjWIhd3yUsCuWNoB/SzSAys5VHGCvWrg7ry4 hNSw== X-Gm-Message-State: ABy/qLaazXu4KXqcvOvlZKuev45rlr8T+wpTtyucUr/toCtCWRNMlLSs jHaNjzEZcQ39KeA7YONW8+KBWvUQgrkZDA== X-Google-Smtp-Source: APBJJlGfoB5mOSjwXB0LlUmRm6G68DEJ5JbxoM9ZTYW/tdfxgsSVCGAkc5PE/lRuIxzrgDQZ9xre+g== X-Received: by 2002:a1c:770a:0:b0:3fa:aeac:e978 with SMTP id t10-20020a1c770a000000b003faaeace978mr268324wmi.0.1689210058020; Wed, 12 Jul 2023 18:00:58 -0700 (PDT) Message-ID: Date: Thu, 13 Jul 2023 03:00:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: musl@lists.openwall.com, Rich Felker , "Appelmans, Madeleine" References: <20230712024804.GH4163@brightrain.aerifal.cx> Content-Language: en-US From: Gabriel Ravier In-Reply-To: <20230712024804.GH4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Difference in pthread behavior between glibc and musl 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. 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 done in cases where they wanted to specify a behavior but had to back down on making it mandatory on the basis of certain implementations complaining that it was too complicated to implement and/or wanting to retain another behavior for backwards compatibility or other stuff like that - i.e. they would very much prefer implementations where it isn't particularly burdensome to implement it to do so.