]> granicus.if.org Git - postgresql/commit
Fix SSL deadlock risk in libpq
authorStephen Frost <sfrost@snowman.net>
Mon, 23 Sep 2013 12:33:41 +0000 (08:33 -0400)
committerStephen Frost <sfrost@snowman.net>
Mon, 23 Sep 2013 12:33:41 +0000 (08:33 -0400)
commitb37c90f11e3c239b999f98ffd3bbea6b8253fffa
tree14323c8cf3315dba76e6b8a4fc0460bbc2c675cc
parentb882246e3ab4382b3c9f58e5f85dd8c9e3eb594f
Fix SSL deadlock risk in libpq

In libpq, we set up and pass to OpenSSL callback routines to handle
locking.  When we run out of SSL connections, we try to clean things
up by de-registering the hooks.  Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered during
SSL cleanup which lead to deadlocking.  This moves the thread callback
cleanup to be after all SSL-cleanup related OpenSSL library calls.
I've been unable to reproduce the deadlock with this fix.

In passing, also move the close_SSL call to be after unlocking our
ssl_config mutex when in a failure state.  While it looks pretty
unlikely to be an issue, it could have resulted in deadlocks if we
ended up in this code path due to something other than SSL_new
failing.  Thanks to Heikki for pointing this out.

Back-patch to all supported versions; note that the close_SSL issue
only goes back to 9.0, so that hunk isn't included in the 8.4 patch.

Initially found and reported by Vesa-Matti J Kari; many thanks to
both Heikki and Andres for their help running down the specific
issue and reviewing the patch.
src/interfaces/libpq/fe-secure.c