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.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 e0e76c73 for ; Wed, 19 Feb 2020 00:46:50 +0000 (UTC) Received: (qmail 23768 invoked by uid 550); 19 Feb 2020 00:46:49 -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 23735 invoked from network); 19 Feb 2020 00:46:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newmedia-net.de; s=mikd; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:To:From:Subject; bh=kikYvXZIccv7n1q2WLK8zJACpKW/lkVZ9vm/J36mzDQ=; b=hvp3KCrNRyPFWqErvMwmNLnLFPOqV6F5D+zFfzAufM30IHQX36wXAGqIAbkxebwTylfUF6TMqB6pPmThLb2OYifc5tHr/apxpfXiFUj3YgXJzGdg868Cn637j7HrMv4ZQy+A4ftTBF4fksN+nG87UljxJFgW5gdWheACZP12OGE=; From: Sebastian Gottschall To: musl@lists.openwall.com References: <543bcfcc-41f8-6960-8b6a-8e7fd5f01a01@adelielinux.org> <20200218222325.la2lz2yiny6rm47u@gentoo-zen2700x> Message-ID: <8a85b4ac-e1ed-dc30-bdad-b1e33ed20257@newmedia-net.de> Date: Wed, 19 Feb 2020 01:46:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94BD44E98F7DAAD56F9DE9AD" X-Received: from [2a01:7700:8040:a100:5044:e4be:9cc3:3abb] by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1j4DTA-0001J0-Nd for musl@lists.openwall.com; Wed, 19 Feb 2020 01:44:04 +0100 Subject: [musl] race condition in sem_wait This is a multi-part message in MIME format. --------------94BD44E98F7DAAD56F9DE9AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. from my point of view the bug is in sem_timedwait.c         if (!sem_trywait(sem)) return 0;         int spins = 100;         while (spins-- && sem->__val[0] <= 0 && !sem->__val[1]) a_spin();         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 or am i wrong here? Sebastian --------------94BD44E98F7DAAD56F9DE9AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.
from my point of view the bug is in sem_timedwait.c

        if (!sem_trywait(sem)) return 0;

        int spins = 100;
        while (spins-- && sem->__val[0] <= 0 && !sem->__val[1]) a_spin();

        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

or am i wrong here?


Sebastian


--------------94BD44E98F7DAAD56F9DE9AD--