Description of problem: Version-Release number of selected component (if applicable): strongswan-5.9.5-2.el9.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
... PKCS11 module '<name>' lacks library path created TUN device: ipsec0 listening on IPv6 interface ipsec0, fe80::8c6d:b1ce:d325:2855%121#53 charon-systemd[332232]: segfault at 28 ip 00007f1037e73fbf sp 00007ffc1aea2540 error 4 in libstrongswan-kernel-libipsec.so[7f1037e72000+3000] Code: df 00 00 00 48 8b 03 48 8d 35 6d 10 00 00 48 8b 55 20 48 89 c7 ff 50 08 48 8b 03 48 8b 90 a8 00 00 00 4c 8b 68 10 48 8b 45 20 <4c> 8b 62 28 48 89 c7 ff 50 38 4c 89 e9 48 8d 35 ba 10 00 00 48 89 <info> [1643464651.6282] manager: (ipsec0): new Tun device (/org/freedesktop/NetworkManager/Devices/122) Started Process Core Dump (PID 332238/UID 0). Resource limits disable core dumping for process 332232 (charon-systemd).
Hello, we face the same issue with strongswan and would therefore like to know if there is a timeline when we can expect a fix for this problem. This issue blocks us currently proceeding in one of our most important projects. Thanks a lot for a quick answer from you. Regards, Markus
Similar issue with strongswan-5.9.5-2.el9.x86_64 and CentOS Stream 9 kernel-5.14.0-58.el9.x86_64: kernel: swanctl[188734]: segfault at 18 ip 00007f1134fdf08c sp 00007ffcab2611b0 error 4 in libc.so.6[7f1134f61000+176000] kernel: Code: 0f 11 07 0f 11 47 20 8b 06 8b 56 04 89 47 30 31 c0 85 d2 0f 95 c0 89 47 1c 31 c0 c3 66 90 f3 0f 1e fa 41 54 55 53 48 89 fb 90 <8b> 57 18 64 8b 04 25 d0 02 00 00 39 c2 0f 84 91 00 00 00 83 7f 30 (gdb) where #0 0x00007fa64cadc08c in pthread_rwlock_rdlock.5 () from /lib64/libc.so.6 #1 0x00007fa64c3459ad in CRYPTO_THREAD_read_lock (lock=<optimized out>) at crypto/threads_pthread.c:85 #2 0x00007fa64c33e9a6 in ossl_lib_ctx_get_data (ctx=0x7fa64c5b1520 <default_context_int.lto_priv>, index=1, meth=0x7fa64c56ad40 <provider_store_method.lto_priv>) at crypto/context.c:396 #3 0x00007fa64c34afa5 in get_provider_store (libctx=<optimized out>) at crypto/provider_core.c:334 #4 provider_deactivate (prov=prov@entry=0x55910d670c70, upcalls=upcalls@entry=1, removechildren=removechildren@entry=1) at crypto/provider_core.c:1032 #5 0x00007fa64c34c3ec in ossl_provider_deactivate (removechildren=1, prov=0x55910d670c70) at crypto/provider_core.c:1189 #6 OSSL_PROVIDER_unload (prov=0x55910d670c70) at crypto/provider.c:62 #7 0x00007fa64c5c40e1 in destroy.lto_priv () from /usr/lib64/strongswan/plugins/libstrongswan-openssl.so #8 0x00007fa64cc79d52 in plugin_entry_destroy () from /usr/lib64/strongswan/libstrongswan.so.0 #9 0x00007fa64cc7c071 in unload () from /usr/lib64/strongswan/libstrongswan.so.0 #10 0x00007fa64cc7c0dd in destroy.lto_priv () from /usr/lib64/strongswan/libstrongswan.so.0 #11 0x00007fa64cc62f08 in library_deinit () from /usr/lib64/strongswan/libstrongswan.so.0 #12 0x00007fa64ca8e475 in __run_exit_handlers () from /lib64/libc.so.6 #13 0x00007fa64ca8e5f0 in exit () from /lib64/libc.so.6 #14 0x00007fa64ca76e57 in __libc_start_call_main () from /lib64/libc.so.6 #15 0x00007fa64ca76efc in __libc_start_main_impl () from /lib64/libc.so.6 #16 0x000055910c7c87c5 in _start () Legacy mode with strongswan-starter.service works.
Please check the resolution here: https://github.com/strongswan/strongswan/issues/921 "... The problem seems to be the atexit() handler we use to deinitialize libstrongswan in some executables. We register this handler before loading the plugins and when the openssl plugin is initialized and libcrypto is loaded it registers its own atexit()-handler to cleanup (in particular unload providers), which will run before the one we registered. So when libstrongswan eventually unloads the plugins, OpenSSL has already been deinitialized and trying to unload the providers again will cause this crash. I've pushed a fix for this to the 921-openssl-cleanup branch. ..." The fix is added to the 5.9.6 milestone.
Created attachment 1863097 [details] strongswan.spec Updated spec file
Created attachment 1863098 [details] strongswan-5.9.5-atexit-handlers.patch Patch file which fixes the issue.
I built an updated package strongswan-5.9.5-3.el9.x86_64 (https://copr.fedorainfracloud.org/coprs/areiter/centos-stream-9-extra/repo/epel-9/areiter-centos-stream-9-extra-epel-9.repo). The updated version fixes the issue.
Thanks! If you'd like, feel free to put up a PR against the epel9 branch on https://src.fedoraproject.org/rpms/strongswan . Otherwise I'll get your fixes imported and a new version built later in the week.
I added the PR against the epel9 branch https://src.fedoraproject.org/rpms/strongswan/pull-request/15
FEDORA-EPEL-2022-c3930ae008 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c3930ae008
FEDORA-EPEL-2022-c3930ae008 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c3930ae008 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-3e8ef6b1f2 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3e8ef6b1f2
FEDORA-2022-3e8ef6b1f2 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-c3930ae008 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.