From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a6cb4446 for ; Mon, 10 Feb 2020 20:23:34 +0000 (UTC) Received: (qmail 23868 invoked by uid 550); 10 Feb 2020 20:23:32 -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 23850 invoked from network); 10 Feb 2020 20:23:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581366200; bh=jGR6wWzn1GMpxZ36ZhQN4doL28RJcguR5bvFZcoYOtM=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=C0yb43fl5nQIk7PyzPocQ3DEK2QyMERaMLJDChDNN3GQqmuL5vfJWIdCLcgFQWgPv iLgHHxph22gDm4lbzaRe6Ca+Zs4x9SKGvcmAkhEUgFNe3k4OTgYnI1i1d3ZqtRSTz3 BQ34qveIWtvAgcxa0PrjaMEd1krcBWhF8/uGccTs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 10 Feb 2020 21:23:20 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200210202320.GA3383@voyager> References: <20200210193427.GR1663@brightrain.aerifal.cx> <14a8dbf3-1382-e61c-3b4e-3a3174dd75b2@bell-sw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <14a8dbf3-1382-e61c-3b4e-3a3174dd75b2@bell-sw.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:fP/jbjezoGBIvy2H/9hVbD7Ge7+wn2nuX38rlPKcHvE2hKxVJfT VI79l/gcXXB0bVAfJ+qUc2XTsnt7dzdTBXg7q5+QpMtpp+iXbhLvajKV/dE4z0mymfytcz+ P4NyKAXGHLt8kG5EP5JEqNHSKIwkU2vFIeDkaSS+skO+7mWKxPtYCoenhIZ6AspFsHmTBpH BJ95h6Jjy97guqQt36JXQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Nc9UfWu46V0=:shR9Q2qPncya6fZBKx3x5e yvD1vjhsNZBUP2qyCCjzXDOQA172TkxGKRuGQunvqbE7jFWGZBebNEYatv9LYgmyMA4p8vkzv Xz7UX52GsOuAJwcFNwZD6bSa6ioqsPoVOiYedkAjPteOqeDoUeRwqw/PJR9ojmjwvrOmrCGFP IfqlKfaxK9PVssnPALjeX2dDBhIAQRdvbN01MBbllRfxciU5GwsfUa0bHQElhmGEF8/sz6dwM GZygTAaH3J692cByTtOMqXynXXvRSMEC9Bh71pYnPVv2CHkb2eU2zGuqKA5ttSFWMZ16Y46Sw KztcAe42COga87Bn6q966ta2Ehkw0EyRKElsWE5nK9nfH42uIwX0xfuFH0RCmD+Vvz0BNPyQu cN1iAq5BqjF0aFhyFcorsECY8K+oR9rfIEX5qP0UlvlDsLcCwSVVJu8Rr7DKn5urEVBN5s5Eb C+8k3pVaiJECMDlUioODP6y3Zbfx/65RKIJ5OX9nHfeh/s4EvD9kRqupmkDYxW1Wta5YdV2Zg oe3pEvSX/Zi0Q0W7E8TNQkXpM2HxZHat6dpAKCEMPg3YMZEyDQGl7Td3Ed1XOd70RVWx2T9rg XE1FrWlhgCgBMLlMHI9Ploa+YlGqZpfqv2+Ppqwha4Qi0N1abMK1+W8C1/reyO+DlBYRpAgLw NHHVIgc+B96wrMw4A5+Zmy5WIuEsGt2p5VL3dRzU8lKsxGCr2cWTnIXHqhiJuqk5bYQ/EaSnU nlx5CJt7fYqnY2U6flWCZe4muYwx8DZnUzTr7YHFQrQqQMNlx7pVcjdE7OART5KD2DJwQz65+ HvBR4jp/xj20w8aG/seKefv+fPj2pncITDrE41J22zbp3cMliLRYWKGsfH0ausqLIBKHfPKOX 084xJd9RD2H3zUU4XbH4mkUItLtpk0wRjbEhtrOi2tSXtU/l6czqlg6B76/1CbhZEBwMDUDHo erLd65/ZcvfwcGIuwLUmXFSNnE9novJDTgU/ZO6FT3tBl+uyrGKlvi2c9Hp1i8n4hU3Yd5g6O peEOqXMroOzz9BWmAiLcsXArb9bMrsRD+Rx8xBD+p0QP3/me7RBdPShshRUWSyGbpKDhcZkSY ipBTNxfun0jfbOycBEnslJjjDRFu5jQ5vRjAe5g9ItUQVP8a/WtxdN9LF5NpeEn5u3eODfXWA ghs4LK6/R31MxGXUiN5K/XJJMKjXZSNFuRc1v4uVJSgSWmXUNsDxprWV1IdIYia9LKVVzEc8V MEnv1F+jje9UJcPzg Subject: Re: [musl] No such process return value in pthread_getcpuclockid On Mon, Feb 10, 2020 at 10:57:22PM +0300, Alexander Scherbatiy wrote: > I can create a thread, join to it and use the thread id in > pthread_getcpuclockid function after that. > Nope, that's a use after free. Joining a thread has the effect of invalidating all outstanding pthread_ts for the joined thread. > The Linux Programmer's Manual has the following errors section: "ESRCH= =A0 No > thread with the ID thread could be found." > And POSIX says "No errors are defined." I'm guessing POSIX wins. Use-after-free in this case would be dangerous even if it did not crash. See, once a thread is joined, the pthread_t is invalidated, but it may be reused. Another thread may immediately create another thread that coincidentally allocates the pthread_t in exactly the same place as the old pthread_t was. Not as coincidental as one might think if both threads have the same stack and guard size. Once that has happened, pthread_getcpuclockid (or any other pthread_* function) will access a different thread than you intended. It is a logic error to do what you want to do, and crashing is one of the best things that can happen to you if you try. The other possibility is a really subtle bug that only occurs sometimes. Happy debugging! > Does pthread_getcpuclockid function from musl follows the similar errors > handling approach? > Musl's pthread_getcpuclockid() cannot fail at this time. It can only succeed or crash. Ciao, Markus