Description of problem: I use the "pidgin" messaging app, and since upgrading to Fedora 32, every time I exit the application, it gets stuck in a 100% CPU burning loop triggered by an openssl atexit handler. Openssl is attempting to unlock a rwlock, and the glibc impl is spinning on a loop. The stack trace is: #0 0x00007f3195a08ae7 in __pthread_rwlock_wrlock_full (abstime=0x0, clockid=0, rwlock=0x55c3ec2d5a80) at pthread_rwlock_common.c:942 #1 __GI___pthread_rwlock_wrlock (rwlock=0x55c3ec2d5a80) at pthread_rwlock_wrlock.c:27 #2 0x00007f318697387d in CRYPTO_THREAD_write_lock (lock=<optimized out>) at crypto/threads_pthread.c:78 #3 0x00007f31868d7825 in ENGINE_finish (e=0x55c3ec1bad30) at crypto/engine/eng_init.c:101 #4 0x00007f3185f5ae8b in OSSLCryptoFactory::~OSSLCryptoFactory() () at /usr/lib64/pkcs11/libsofthsm2.so #5 0x00007f3185f5af1d in OSSLCryptoFactory::~OSSLCryptoFactory() () at /usr/lib64/pkcs11/libsofthsm2.so #6 0x00007f319586d3d7 in __run_exit_handlers (status=0, listp=0x7f31959f1578 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #7 0x00007f319586d580 in __GI_exit (status=<optimized out>) at exit.c:139 #8 0x00007f3195855049 in __libc_start_main (main= 0x55c3ea79d280 <main>, argc=1, argv=0x7ffe632abe08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe632abdf8) at ../csu/libc-start.c:342 #9 0x000055c3ea79e26e in _start () I'm unclear which component here is at fault as mulitple codebases are involved here, softhsm, openssl, glibc, pidgin. I'm picking openssl as the component for this bug as it is in the stack trace closest to glibc, but feel free to reassign if needed Version-Release number of selected component (if applicable): openssl-1.1.1g-1.fc32.x86_64 softhsm-2.6.1-1.fc32.x86_64 pidgin-2.13.0-18.fc32.x86_64 glibc-2.31-2.fc32.x86_64 How reproducible: Always Steps to Reproduce: 1. Start pidgin app 2. Exit pidgin app 3. Actual results: App appears closed, but its process still exists, stuck burning 100% cpu Expected results: Process exits fully Additional info:
This looks like a duplicate as softhsm is involved here. *** This bug has been marked as a duplicate of bug 1831086 ***
IMHO it would be desirable if openssl did more robust cleanup to avoid the danger of use after free. At the very least setting "global_engine_lock = NULL" in engine_cleanup_int should have caused this to crash immediately rather proceed to access free'd memory and burn 100% CPU.
I can propose it upstream.
Upstream PR created.