[Samba] bind9 failure when using dlz_bind

[Michael Tokarev]

On 6/28/24 08:16, Douglas Bagnall wrote:

> And yes, a backtrace will help.


$ gdb /usr/sbin/named
GNU gdb (Debian 13.2-1+b2) 13.2

(gdb) ru -4 -d10 -n1 -f -p54 -L /dev/stdout
Starting program: /usr/sbin/named -4 -d10 -n1 -f -p54 -L /dev/stdout
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3b7f680 (LWP 546107)]

Thread 1 "named" received signal SIGSEGV, Segmentation fault.
0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) bt
#0  0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6f35669 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6f37e2f in free () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff13e1155 in ?? () from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
#4  0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0, reference_ctx=0x7ffff4235d20) at source4/dsdb/schema/schema_set.c:896
#5  0x00007ffff13e0d5c in ?? () from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
#6  0x00007ffff463f2c2 in ldb_module_init_chain () from /lib/x86_64-linux-gnu/libldb.so.2
#7  0x00007ffff463f2c2 in ldb_module_init_chain () from /lib/x86_64-linux-gnu/libldb.so.2
#8  0x00007ffff143cdd4 in ?? () from /usr/lib/x86_64-linux-gnu/samba/ldb/rootdse.so
#9  0x00007ffff463f2c2 in ldb_module_init_chain () from /lib/x86_64-linux-gnu/libldb.so.2
#10 0x00007ffff1410f13 in ?? () from /usr/lib/x86_64-linux-gnu/samba/ldb/samba_dsdb.so
#11 0x00007ffff463f2c2 in ldb_module_init_chain () from /lib/x86_64-linux-gnu/libldb.so.2
#12 0x00007ffff463f3ac in ldb_load_modules () from /lib/x86_64-linux-gnu/libldb.so.2
#13 0x00007ffff463e2be in ldb_connect () from /lib/x86_64-linux-gnu/libldb.so.2
#14 0x00007ffff2455435 in samba_ldb_connect (ldb=ldb at entry=0x7ffff4288fe0, lp_ctx=lp_ctx at entry=0x7ffff3cd8720,
     url=url at entry=0x7ffff43fa960 "/var/lib/samba/bind-dns/dns/sam.ldb", flags=flags at entry=64) at lib/ldb-samba/ldb_wrap.c:230
#15 0x00007ffff321a678 in samdb_connect_url (mem_ctx=mem_ctx at entry=0x7ffff4277de0, ev_ctx=0x7ffff42b1720, lp_ctx=0x7ffff3cd8720,
     session_info=0x7ffff3cd8a20, flags=64, flags at entry=0, url=url at entry=0x7ffff43fa960 "/var/lib/samba/bind-dns/dns/sam.ldb",
     remote_address=0x0, ldb_ret=0x7ffff4277df0, errstring=0x7fffffff8be0) at source4/dsdb/samdb/samdb.c:96
#16 0x00007ffff47aba6e in dlz_create (dlzname=<optimized out>, argc=1, argv=0x7ffff42ec288, dbdata=0x7ffff42776a8)
     at source4/dns_server/dlz_bind9.c:741
#17 0x0000555555579126 in ?? ()
#18 0x00007ffff7b4f49a in ?? () from /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
#19 0x00007ffff7a5b105 in dns_dlzcreate () from /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
#20 0x000055555558cf07 in ?? ()
#21 0x000055555559d88f in ?? ()
#22 0x000055555559eb81 in ?? ()
#23 0x00007ffff7c6e537 in isc.async_cb () from /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
#24 0x00007ffff737cd33 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#25 0x00007ffff7390a72 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#26 0x00007ffff737d9f8 in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#27 0x00007ffff7c81850 in ?? () from /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
#28 0x000055555556e97a in main ()

(gdb) frame 3
#3  0x00007ffff13e1155 in ?? () from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so

(gdb) frame 4
#4  0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0, reference_ctx=0x7ffff4235d20) at source4/dsdb/schema/schema_set.c:896
896				schema_out = refresh_fn(loaded_from_module,
(gdb) l
891			/* We need to guard against recursive calls here */
892			if (ldb_set_opaque(ldb, "dsdb_schema_refresh_fn", NULL) != LDB_SUCCESS) {
893				ldb_debug_set(ldb, LDB_DEBUG_FATAL,
894					      "dsdb_get_schema: clearing dsdb_schema_refresh_fn failed");
895			} else {
896				schema_out = refresh_fn(loaded_from_module,
897							ldb_get_event_context(ldb),
898							schema_in,
899							use_global_schema);
900			}

Smells like the stack is damaged..
-- 
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt