I've got two RHEL 8 servers where named-pkcs11 aborts with an assertion failure after upgrading bind to version 32:9.11.36-11.el8_9.1.
``` Apr 13 15:54:50 named-pkcs11[372364]: zone localhost/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone localhost.localdomain/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: all zones loaded Apr 13 15:54:50 named-pkcs11[372364]: running Apr 13 15:54:50 named-pkcs11[372364]: ../../../lib/dns-pkcs11/name.c:1116: REQUIRE((target != ((void *)0) && (__builtin_expect(((target) != ((void *)0)), 1) && __builtin_ex> Apr 13 15:54:50 systemd[1]: named-pkcs11.service: New main PID 372364 does not belong to service, and PID file is not owned by root. Refusing. Apr 13 15:54:50 named-pkcs11[372364]: #0 0x563c05be4d14 in ?? Apr 13 15:54:50 systemd[1]: named-pkcs11.service: New main PID 372364 does not belong to service, and PID file is not owned by root. Refusing. Apr 13 15:54:50 named-pkcs11[372364]: #1 0x7fb179f28fe0 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #2 0x7fb17a23b7b2 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #3 0x7fb1687e4156 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #4 0x7fb1687e45e1 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #5 0x7fb1687e5e60 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #6 0x7fb1687e6214 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #7 0x7fb1687ef3e0 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #8 0x7fb179f50904 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #9 0x7fb179f5158f in ?? Apr 13 15:54:50 named-pkcs11[372364]: #10 0x7fb17733e1ca in ?? Apr 13 15:54:50 named-pkcs11[372364]: #11 0x7fb176c42e73 in ?? Apr 13 15:54:50 named-pkcs11[372364]: exiting (due to assertion failure) ```
Downgrading to 9.11.36-11.el8_9.x86_64 fixes the problem.
Here's the stack trace from 'coredumpctl info named-pkcs11':
``` Stack trace of thread 325662: #0 0x00007f0575081acf raise (libc.so.6) #1 0x00007f0575054ea5 abort (libc.so.6) #2 0x0000557c3cbecd2a assertion_failed.cold.5 (named-pkcs11) #3 0x00007f0578352fe0 isc_assertion_failed (libisc-pkcs11.so.1107) #4 0x00007f05786657b2 dns_name_fromtext (libdns-pkcs11.so.1115) #5 0x00007f056e20b156 empty_zone_search_next (ldap.so) #6 0x00007f056e20b5e1 empty_zone_handle_conflicts (ldap.so) #7 0x00007f056e20ce60 fwd_configure_zone (ldap.so) #8 0x00007f056e20d214 fwd_reconfig_global (ldap.so) #9 0x00007f056e2163e0 update_serverconfig (ldap.so) #10 0x00007f057837a904 dispatch (libisc-pkcs11.so.1107) #11 0x00007f057837b58f run_normal (libisc-pkcs11.so.1107) #12 0x00007f05757681ca start_thread (libpthread.so.0) #13 0x00007f057506ce73 __clone (libc.so.6) ```
I can open a Jira, attach coredumps, etc. next week if needed.
```
On Sat, 2024-04-13 at 17:06 +0100, Sam Morris via FreeIPA-users wrote:
I've got two RHEL 8 servers where named-pkcs11 aborts with an assertion failure after upgrading bind to version 32:9.11.36-11.el8_9.1.
Apr 13 15:54:50 named-pkcs11[372364]: zone localhost/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone localhost.localdomain/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arp a/IN: loaded serial 0 Apr 13 15:54:50 named-pkcs11[372364]: all zones loaded Apr 13 15:54:50 named-pkcs11[372364]: running Apr 13 15:54:50 named-pkcs11[372364]: ../../../lib/dns- pkcs11/name.c:1116: REQUIRE((target != ((void *)0) && (__builtin_expect(((target) != ((void *)0)), 1) && __builtin_ex> Apr 13 15:54:50 systemd[1]: named-pkcs11.service: New main PID 372364 does not belong to service, and PID file is not owned by root. Refusing. Apr 13 15:54:50 named-pkcs11[372364]: #0 0x563c05be4d14 in ?? Apr 13 15:54:50 systemd[1]: named-pkcs11.service: New main PID 372364 does not belong to service, and PID file is not owned by root. Refusing. Apr 13 15:54:50 named-pkcs11[372364]: #1 0x7fb179f28fe0 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #2 0x7fb17a23b7b2 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #3 0x7fb1687e4156 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #4 0x7fb1687e45e1 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #5 0x7fb1687e5e60 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #6 0x7fb1687e6214 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #7 0x7fb1687ef3e0 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #8 0x7fb179f50904 in ?? Apr 13 15:54:50 named-pkcs11[372364]: #9 0x7fb179f5158f in ?? Apr 13 15:54:50 named-pkcs11[372364]: #10 0x7fb17733e1ca in ?? Apr 13 15:54:50 named-pkcs11[372364]: #11 0x7fb176c42e73 in ?? Apr 13 15:54:50 named-pkcs11[372364]: exiting (due to assertion failure)
Downgrading to 9.11.36-11.el8_9.x86_64 fixes the problem.
I had the same yesterday, so I rolled back the VMs to before the last update. When I tried again today I had no problems anymore. I guess due to the fact that the update installed an updated bind-dyndb-ldap. This has the following in the changelog: * Thu Mar 28 2024 Rafael Jeffman rjeffman@redhat.com - 11.6-5 - Rebuild due to Bind ABI changes (CVE 2023-50387). Resolves: RHEL-28847
BR, Louis
On Sat, 2024-04-13 at 19:03 +0200, Louis Lagendijk via FreeIPA-users wrote:
I had the same yesterday, so I rolled back the VMs to before the last update. When I tried again today I had no problems anymore. I guess due to the fact that the update installed an updated bind-dyndb-ldap. This has the following in the changelog:
- Thu Mar 28 2024 Rafael Jeffman rjeffman@redhat.com - 11.6-5
- Rebuild due to Bind ABI changes (CVE 2023-50387).
Resolves: RHEL-28847
Thanks, you're quite correct. On these servers I have dnf-automatic set to apply security updates only, so bind-dyndb-ldap didn't get pulled in. Upgrading that package fixed things.
BR, Louis
freeipa-users@lists.fedorahosted.org