[CDRIVER-2605] OpenSSL thread and id callbacks should be unset independently Created: 11/Apr/18  Updated: 28/Oct/23  Resolved: 11/Apr/18

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 1.9.3
Fix Version/s: 1.10.0

Type: Bug Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Jeremy Mikola
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

PHP (mongodb, curl, and openssl extensions), OpenSSL 1.0.2m


Issue Links:
Depends
is depended on by PHPC-1158 Segfault during OpenSSL cleanup routines Closed
Related
is related to CDRIVER-555 Segfault during OpenSSL cleanup routines Closed

 Description   

PHPC-1158 describes a situation where multiple PHP extensions interacting with OpenSSL resulted in a dangling function pointer to libmongoc's thread id callback being left in place. This ultimately produced a segfault during cURL's shutdown routines, which also interacted with OpenSSL and attempted to invoke that callback after libmongoc had already been unloaded (i.e. dlclose()).

This previously came up in CDRIVER-555. The fix (746d250, released in 1.1.2) introduced the logic we see today that checks the locking callback before assigning or unsetting libmongoc's callbacks.

I propose that _mongoc_openssl_thread_cleanup() be improved to clear the locking and id callbacks independently if either is still assigned to the libmongoc function. _mongoc_openssl_thread_startup() can be left as-is and only assign locking and id callbacks if the locking callback is currently unset.



 Comments   
Comment by Githook User [ 11/Apr/18 ]

Author:

{'email': 'jmikola@gmail.com', 'name': 'Jeremy Mikola', 'username': 'jmikola'}

Message: CDRIVER-2605 unset OpenSSL id callback independently
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/4236b470baaa512cf8abdbea09ffa04e727b72e7

Comment by Jeremy Mikola [ 11/Apr/18 ]

https://github.com/mongodb/mongo-c-driver/pull/490

Generated at Wed Feb 07 21:15:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.