Bug 17013 - pthread_cond_broadcast could call lll_unlock() twice, breaking the shared data
Summary: pthread_cond_broadcast could call lll_unlock() twice, breaking the shared data
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-03 22:26 UTC by Hideaki Kimura
Modified: 2016-08-16 10:49 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hideaki Kimura 2014-06-03 22:26:52 UTC
This reports an already-fixed bug that was in glibc 2.18 and 2.19.
The fix will be in the upcoming glibc 2.20, but many linux distros would employ it much later.

For helping backport request in individual linux distros, I'd like to put relevant information here.

An example error case I hit:
  - Several waitors wait on pthread_cond_wait with holding mutex.
  - One signal-er calls broadcast with holding mutex
  - The thread that invoked pthread_cond_broadcast occasionally hangs.
When I attach gdb, the hanging thread is waiting at lll_lock_wait() even though there are no concurrent threads.

According to the commit history, it was caused by a commit on Feb 2013;
commit 8313cb997d2d("FUTEX_*_REQUEUE_PI support for
non-x86 code").

Then, it was fixed by this commit on Apr 2014;
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8f630cca5c36941db1cb48726016bbed80ec1041

So, the affected versions of glibc should be 2.18 and 2.19.

Yang/Siddhesh, does it sound right?
Comment 1 Siddhesh Poyarekar 2014-06-04 07:01:45 UTC
You can ask individual distributions to backport the fix.  I can backport it to the upstream 2.18 and 2.19 branches, but that won't help.

I've marked the bug as WAITING to know if you want to pursue fixing this in the upstream stable branches.  What you really need though is to create bugs in the distribution you use, asking to backport this fix.
Comment 2 Hideaki Kimura 2014-06-04 17:55:38 UTC
(In reply to Siddhesh Poyarekar from comment #1)
> You can ask individual distributions to backport the fix.  I can backport it
> to the upstream 2.18 and 2.19 branches, but that won't help.
> 
> I've marked the bug as WAITING to know if you want to pursue fixing this in
> the upstream stable branches.  What you really need though is to create bugs
> in the distribution you use, asking to backport this fix.

Yes, I did file a backport request to Fedora, pointing to this ticket.
  https://bugzilla.redhat.com/show_bug.cgi?id=1104400
I'm in the course of doing it to other linux distro, probably Ubuntu.

If you backport it to upstream glibc 2.18/2.19, I guess it will help the distro maintainers (not quite sure as I don't know how distro maintainers retrieve patches to glibc).
Comment 3 Florian Weimer 2015-02-18 14:37:58 UTC
This may have security implications.  I asked on libc-alpha, on the original thread: https://sourceware.org/ml/libc-alpha/2015-02/msg00510.html
Comment 4 Adhemerval Zanella 2016-08-15 21:47:53 UTC
I am closing this bug since it has been fixed upstream.
Comment 5 Florian Weimer 2016-08-16 10:49:44 UTC
I no longer think this needs to be treated as a security issue.