Skip Menu |
 

History Show all quoted text — Show full headers
# Wed May 01 16:56:05 2013 Arlene Berry <arlene.berry@isilon.com> - Ticket created
Subject: g_initialize.c build_MechSet potential to leak a lock
Date: Wed, 1 May 2013 12:43:40 -0700
From: Arlene Berry <arlene.berry@isilon.com>
To: <krb5-bugs@mit.edu>
Download (untitled) / with headers
text/plain 216B
Download (untitled) / with headers
text/html 1.7KiB

In src/lib/gssapi/mech/glue/g_initialize.c if build_mechSet() successfully locks g_mechListLock but fails to lock g_mechSetLock, you would leak the first lock.  It’s unlikely and we haven’t actually seen it happen.

# Wed May 01 20:05:16 2013 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'resolved'
# Wed May 01 20:05:16 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 263B
In January 2012 we agreed to update our portability assumptions to include
the assumption that locking a non-recursive mutexes will never fail. We
haven't updated the code to remove all of the conditionals yet, but it's
not really worth fixing this logic bug.
# Wed May 01 20:05:35 2013 ghudson@mit.edu (Greg Hudson) - Tags nochange added