This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix lll_unlock twice in pthread_cond_broadcast
- From: Florian Weimer <fweimer at redhat dot com>
- To: Yang Yingliang <yangyingliang at huawei dot com>, libc-alpha at sourceware dot org
- Cc: siddhesh at redhat dot com
- Date: Wed, 18 Feb 2015 15:36:10 +0100
- Subject: Re: [PATCH] Fix lll_unlock twice in pthread_cond_broadcast
- Authentication-results: sourceware.org; auth=none
- References: <1398850798-5648-1-git-send-email-yangyingliang at huawei dot com>
On 04/30/2014 11:39 AM, Yang Yingliang wrote:
> lll_unlock() will be called again if it goes to "wake_all"
> in pthread_cond_broadcast(). This may make another thread
> which is waiting for lock in pthread_cond_timedwait() unlock.
> So there are more than one threads get the lock, it will break
> the shared data.
>
> It's introduced by commit 8313cb997d2d("FUTEX_*_REQUEUE_PI support for non-x86 code")
Is there a bug for this?
Lack of mutual exclusion could be a potential security issue. Can this
happen with regular mutexes/condition variables?
--
Florian Weimer / Red Hat Product Security