Description of problem: certmonger segfaults when having created a certificate with an empty nickname. Version-Release number of selected component (if applicable): certmonger-0.79.13-2.fc34.x86_64 How reproducible: Steps to Reproduce: 1. getcert request -d /etc/pki/nssdb/ -n "" 2. getcert request -d /etc/pki/nssdb/ -n "" Actual results: Please verify that the certmonger service is still running. Expected results: certmonger does not segfault. Additional info: Aug 19 15:26:44 fedora-34-127-0-0-2-2201 abrt-notification[1881]: [🡕] Process 1806 (certmonger) crashed in __strcmp_avx2() Core was generated by `/usr/sbin/certmonger -S -p /run/certmonger.pid -n -d2'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:102 102 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: No such file or directory. Missing separate debuginfos, use: dnf debuginfo-install libxcrypt-4.4.23-1.fc34.x86_64 nspr-4.31.0-1.fc34.x86_64 nss-3.67.0-1.fc34.x86_64 nss-util-3.67.0-1.fc34.x86_64 systemd-libs-248.6-1.fc34.x86_64 (gdb) bt full #0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:102 No locals. #1 0x00005604392763fc in base_add_request (conn=0x56043ad332c0, msg=<optimized out>, ci=0x7ffdd2a51ec0, ctx=0x56043ad2e550) at /usr/src/debug/certmonger-0.79.13-2.fc34.x86_64/src/tdbush.c:688
I believe this is fixed in 0.79.14 which should be available in F34. Can you test it again? I wasn't able to reproduce it. Upstream issue https://pagure.io/certmonger/issue/191
I can not get 0.79.14 yet in Fedora 34, but I do see it in rawhide. Looking at the fix it should be fixed with that commit.
For full ref, 0.79.14 is still in fedora-testing on f34 as of today. The build can be tested with "dnf update --enablerepo=updates-testing certmonger" and karma can be provided to speed up promoting the build from testing to stable.
@jvanderwaa Can you test it again?
On Fedora 34 with certmonger-0.79.14-2.fc34.x86_64 I can still reproduce the issue with: $ getcert request -d /etc/pki/nssdb/ -n "" $ getcert request -d /etc/pki/nssdb/ -n "" Please verify that the certmonger service is still running Backtrace in journalctl: Nov 11 06:55:13 fedora-34-127-0-0-2-2201 systemd-coredump[27576]: [🡕] Process 27398 (certmonger) of user 0 dumped core. Stack trace of thread 27398: #0 0x00007f4b637c2c12 __strcmp_avx2 (libc.so.6 + 0x15bc12) #1 0x0000563eef3c7fbc base_add_request.lto_priv.0 (certmonger + 0x24fbc) #2 0x0000563eef3c011d cm_tdbus_filter (certmonger + 0x1d11d) #3 0x00007f4b63c692f5 dbus_connection_dispatch (libdbus-1.so.3 + 0x1b2f5) #4 0x0000563eef3bf5b8 cm_tdbus_dispatch_status (certmonger + 0x1c5b8) #5 0x00007f4b63c65dd5 _dbus_connection_update_dispatch_status_and_unlock.lto_pr> #6 0x00007f4b63c65f45 _dbus_connection_handle_watch (libdbus-1.so.3 + 0x17f45) #7 0x0000563eef3bf7c1 cm_tdbus_handle_fd.lto_priv.0 (certmonger + 0x1c7c1) #8 0x00007f4b63c424f5 tevent_common_invoke_fd_handler (libtevent.so.0 + 0xa4f5) #9 0x00007f4b63c4621f epoll_event_loop_once (libtevent.so.0 + 0xe21f) #10 0x00007f4b63c3e69b std_event_loop_once (libtevent.so.0 + 0x669b) #11 0x00007f4b63c40da8 _tevent_loop_once (libtevent.so.0 + 0x8da8) #12 0x0000563eef3b4ee3 main (certmonger + 0x11ee3) #13 0x00007f4b6368eb75 __libc_start_main (libc.so.6 + 0x27b75) #14 0x0000563eef3b5b2e _start (certmonger + 0x12b2e)
Confirmed, thanks. I can reproduce it now. #1 0x0000556a188a1275 in base_add_request (conn=0x556a19e64860, msg=<optimized out>, ci=0x7fffd206b400, ctx=0x556a19e1d640) at tdbush.c:895 895 if (strcmp(key_nickname, The code is: 884 case cm_key_storage_file: 885 if (strcmp(key_location, 886 e->cm_key_storage_location) != 0) { 887 continue; 888 } 889 break; 890 case cm_key_storage_nssdb: 891 if (strcmp(key_location, 892 e->cm_key_storage_location) != 0) { 893 continue; 894 } 895 if (strcmp(key_nickname, 896 e->cm_key_nickname) != 0) { 897 continue; 898 } 899 break; 900 } 901 break; 902 } This should be straightforward and a similar fix to: 0eec70b9dbd0a50a24fe173a68fd9ab72857e08d
Upstream PR https://pagure.io/certmonger/pull-request/230 will reject future requests like this
fixed upstream: fcb0212200fb13d460cc17d7e0818d7e231adb2a
Fixed in release 0.79.15