Date: Tue, 21 Nov 2023 19:40:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 275241] GSS-API aware nsupdate segfaults Message-ID: <bug-275241-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275241 Bug ID: 275241 Summary: GSS-API aware nsupdate segfaults Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: mnowak@startmail.com Created attachment 246472 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D246472&action= =3Dedit tarball with config files When built with `--with-gssapi`, the `nsupdate` command from BIND 9.18 and = 9.16 segfaults in FreeBSD 14.0 gss, spnego, and kerberos library stack. BIND 9.19 (the `main` branch) is not affected. (First identified in https://gitlab.isc.org/isc-projects/bind9/-/issues/4436 when adding FreeBSD 14.0 to the BIND 9 CI.) git clone https://gitlab.isc.org/isc-projects/bind9.git and check out the `bind-9.18` branch. ``` autoreconf -fi ./configure --enable-developer --with-gssapi make -j5 cd bin/tests/system/ sudo ./ifconfig.sh up # setup interfaces for named (i.e., 10.53.0.1) ``` Unpack the issue-4436.tar.xz tarball. Start `named`: ``` ~/bind9/bin/named/named -c named.conf -d 99 -g ``` Run the BIND 9.18 `nsupdate` command with the correct paths to the credenti= al cache and file with `nsupdate` commands: ``` KRB5CCNAME=3D"FILE:"/home/newman/issue-4436/administrator.ccache ~/bind9/bin/nsupdate/nsupdate -g ~/issue-4436/update.txt ``` I get: `Segmentation fault (core dumped)`. Here's a sample GDB backtrace from the `tsiggss` system test (bin/tests/system/tsiggss/): ``` Core was generated by `/root/bind9/bin/nsupdate/.libs/nsupdate -g -d ns1/update.txt'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x00000008316a1a0f in EVP_Cipher () from /lib/libcrypto.so.30 [Current thread is 1 (LWP 188477)] #0 0x00000008316a1a0f in EVP_Cipher () from /lib/libcrypto.so.30 #1 0x000000082e96f4b6 in ?? () from /usr/lib/libkrb5.so.11 #2 0x000000082e973ac8 in krb5_encrypt_ivec () from /usr/lib/libkrb5.so.11 #3 0x000000082e973de5 in krb5_encrypt () from /usr/lib/libkrb5.so.11 #4 0x000000082e9675bf in _krb5_build_authenticator () from /usr/lib/libkrb5.so.11 #5 0x000000082dcff3f6 in ?? () from /usr/lib/libgssapi_krb5.so.10 #6 0x000000082dcfed0b in _gsskrb5_init_sec_context () from /usr/lib/libgssapi_krb5.so.10 #7 0x000000082d95bd4f in gss_init_sec_context () from /usr/lib/libgssapi.s= o.10 #8 0x000000083ed613b6 in ?? () from /usr/lib/libgssapi_spnego.so.10 #9 0x000000083ed5f5c0 in _gss_spnego_indicate_mechtypelist () from /usr/lib/libgssapi_spnego.so.10 #10 0x000000083ed607ee in _gss_spnego_init_sec_context () from /usr/lib/libgssapi_spnego.so.10 #11 0x000000082d95bd4f in gss_init_sec_context () from /usr/lib/libgssapi.s= o.10 #12 0x0000000822a308e5 in dst_gssapi_initctx (name=3D<optimized out>, intoken=3Dintoken@entry=3D0x0, outtoken=3Douttoken@entry=3D0x83d56d700, gssctx=3D0x83d56e218, mctx=3D0x1aef866b3000, err_message=3D0x83d56e200) at gssapictx.c #13 0x0000000822b0c9af in dns_tkey_buildgssquery (msg=3D0x1aef87203a80, name=3D0x2130e0 <fkname>, gname=3D0x1aef87234300, gname@entry=3D0x83d56d7a0, intoken=3D0x1aef872700f0, intoken@entry=3D0x0, lifetime=3Dlifetime@entry=3D= 0, context=3D0xcf, context@entry=3D0x83d56e218, win2k=3D<optimized out>, mctx=3D0x1aef866b3000, err_message=3D0x83d56e200) at tkey.c #14 0x000000000020e790 in start_gssrequest (primary=3Dprimary@entry=3D0x83d= 56e730) at nsupdate.c #15 0x000000000020e33c in recvsoa (task=3D<optimized out>, event=3D0x0) at nsupdate.c #16 0x0000000821c68370 in task_run (task=3D0x1aef8665c140) at task.c #17 isc_task_run (task=3D0x1aef8665c140) at task.c #18 0x0000000821c38689 in isc__nm_async_task (worker=3Dworker@entry=3D0x1aef866d0000, ev0=3D0x1aef872700f0, ev0@entry=3D0x1aef8721c480) at netmgr/netmgr.c #19 0x0000000821c32ec6 in process_netievent (worker=3Dworker@entry=3D0x1aef866d0000, ievent=3Dievent@entry=3D0x1aef8721= c480) at netmgr/netmgr.c #20 0x0000000821c384f2 in process_queue (worker=3Dworker@entry=3D0x1aef866d= 0000, type=3Dtype@entry=3DNETIEVENT_TASK) at netmgr/netmgr.c #21 0x0000000821c2e6bd in process_all_queues (worker=3D0x1aef866d0000) at netmgr/netmgr.c #22 async_cb (handle=3D0x1aef866d02d8) at netmgr/netmgr.c #23 0x0000000829b3c871 in ?? () from /usr/local/lib/libuv.so.1 #24 0x0000000829b4e0fd in ?? () from /usr/local/lib/libuv.so.1 #25 0x0000000829b3ce60 in uv_run () from /usr/local/lib/libuv.so.1 #26 0x0000000821c2e7ab in nm_thread (worker0=3D0x1aef866d0000) at netmgr/ne= tmgr.c #27 0x0000000821c70e46 in isc__trampoline_run (arg=3D0x1aef8662bb90) at trampoline.c #28 0x00000008376e0a75 in ?? () from /lib/libthr.so.3 #29 0x0000000000000000 in ?? () ``` The crash seems to happen not in the BIND 9 code but deep in the FreeBSD 14= .0 stack. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275241-227>