[Bug nptl/20822] New: race condition in __lll_unlock_elision on powerpc

["acsawdey at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20822

            Bug ID: 20822
           Summary: race condition in __lll_unlock_elision on powerpc
           Product: glibc
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: acsawdey at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com, sjmunroe at us dot ibm.com
  Target Milestone: ---
            Target: ppc64le

The update of *adapt_count after the release of the lock causes a race
condition. Mongodb hit this on Ubuntu 16.04 with 2.23. Thread A unlocks, thread
B continues and returns, destroying mutex on stack, then gets into another
function, thread A writes to *adapt_count and corrupts stack.

I changed the value that gets written here and the bytes written to the stack
changed with it, proving that this is where the issue lies. The window is very
narrow and requires that the machine be in smt mode, so likely the two threads
have to be on the same core in order to hit this.

int
__lll_unlock_elision (int *lock, short *adapt_count, int pshared)
{
  /* When the lock was free we're in a transaction.  */
  if (*lock == 0)
    __libc_tend (0);
  else
    {
      lll_unlock ((*lock), pshared);

      /* Update the adapt count AFTER completing the critical section.
         Doing this here prevents unneeded stalling when entering
         a critical section.  Saving about 8% runtime on P8.  */
      if (*adapt_count > 0)
        (*adapt_count)--;
    }
  return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.