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=-3.0 required=5.0 tests=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 01ec67ee for ; Wed, 19 Feb 2020 04:08:20 +0000 (UTC) Received: (qmail 29799 invoked by uid 550); 19 Feb 2020 04:08:19 -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 29781 invoked from network); 19 Feb 2020 04:08:18 -0000 From: Bobby Bingham To: musl@lists.openwall.com References: <543bcfcc-41f8-6960-8b6a-8e7fd5f01a01@adelielinux.org> <20200218222325.la2lz2yiny6rm47u@gentoo-zen2700x> <8a85b4ac-e1ed-dc30-bdad-b1e33ed20257@newmedia-net.de> Date: Tue, 18 Feb 2020 22:07:54 -0600 In-Reply-To: <8a85b4ac-e1ed-dc30-bdad-b1e33ed20257@newmedia-net.de> (Sebastian Gottschall's message of "Wed, 19 Feb 2020 01:46:34 +0100") Message-ID: <87mu9f9q3p.fsf@koorogi.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] race condition in sem_wait Sebastian Gottschall writes: > Hello > > i discovered recently a race condition while playing with threads and > sem_wait/sem_post > sem_wait may fail with errno set EAGAIN which is not valid since only > sem_trywait is able to set that errno code. > this was causing a bug with a later select() and accept() which failed > since accept does not work if errno is set to EAGAIN. Whether select/accept work or not should not be impacted by any existing value in errno. > from my point of view the bug is in sem_timedwait.c > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!sem_trywait(sem)) return = 0; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int spins =3D 100; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 while (spins-- && sem->__val[0= ] <=3D 0 && !sem->__val[1]) a_spin(); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 while (sem_trywait(sem)) { > > > the fist sem_trywait will fail with -1 and sets EAGAIN. but the second > sem_trywait will not fail and does return 0. the problem now is that > errno is still present and not reset. > this may cause if sem_post is called from a second thread on the same > semaphore. > of course the same bug affects sem_timedwait itself. > so i assume sem_wait is not thread safe which is bad and is not follow > the posix specification To quote POSIX [1]: The value of errno should only be examined when it is indicated to be valid by a function's return value. [...] The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified. If sem_wait() returns zero, then the value in errno after the call returns is not meaningful in any way. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html > > or am i wrong here? > > > Sebastian Bobby