Crash on shutdown when DNSSEC validation is running: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed
Summary
(Summarize the bug encountered concisely.)
BIND version used
Does not affect:
- v9.18: 6817bf12
- v9.16: 161d69ab
- v9.11 (EoL): v9.11.37-S1
- Other versions were not tested
Steps to reproduce
Essentially cause validator to work on something during shutdown. One possibility is simply random subdomain attack against a signed zone.
- Run an auth:
- zone: local.testiscorg.ch.zone.signed
- config: auth.conf
named -g -c auth.conf
- Run
named
under attack:
- resolver.conf
named -g -c resolver.conf -n1 -D resolver
The -n1
makes it easier to trigger.
- Run random subdomain attack:
- randnames.py
python randlabels.py | dnsperf -s 127.0.0.1 -S1 -D
- SIGINT the resolver:
pkill -f resolver
What is the current bug behavior?
message.c:4768: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff6bea8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff6b9a668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff6b824b8 in __GI_abort () at abort.c:79
#4 0x000055555557e3b2 in assertion_failed (file=0x7ffff7eae157 "message.c", line=4768, type=isc_assertiontype_ensure, cond=0x7ffff7eaf818 "isc_mempool_getallocated(*namepoolp) == 0") at main.c:234
#5 0x00007ffff7f502ea in isc_assertion_failed (file=0x7ffff7eae157 "message.c", line=4768, type=isc_assertiontype_ensure, cond=0x7ffff7eaf818 "isc_mempool_getallocated(*namepoolp) == 0") at assertions.c:48
#6 0x00007ffff7cf9a59 in dns_message_destroypools (namepoolp=0x7ffff3e38580, rdspoolp=0x7ffff3e38588) at message.c:4768
#7 0x00007ffff7de87c3 in dns_resolver__destroy (res=0x7ffff3e31c00) at resolver.c:9892
#8 0x00007ffff7dea2b4 in dns_resolver_unref (ptr=0x7ffff3e31c00) at resolver.c:10173
#9 0x00007ffff7dea38d in dns_resolver_detach (ptrp=0x7ffff3e6e848) at resolver.c:10173
#10 0x00007ffff7c6ed52 in destroy (adb=0x7ffff3e6e800) at adb.c:1830
#11 0x00007ffff7c6ef20 in dns_adb_unref (ptr=0x7ffff3e6e800) at adb.c:1838
#12 0x00007ffff7c6eff9 in dns_adb_detach (ptrp=0x7fffffff9dc0) at adb.c:1838
#13 0x00007ffff7e26a56 in dns_view_detach (viewp=0x7ffff13b3e08) at view.c:516
#14 0x00007ffff7e237dd in destroy_validator (val=0x7ffff13b3e00) at validator.c:3122
#15 0x00007ffff7e23f49 in dns_validator_unref (ptr=0x7ffff13b3e00) at validator.c:3226
#16 0x00007ffff7e24022 in dns_validator_detach (ptrp=0x7fffffff9fa0) at validator.c:3226
#17 0x00007ffff7e1c421 in validator_done_cb (arg=0x7ffff13b3e00) at validator.c:211
#18 0x00007ffff7f507ac in isc__async_cb (handle=0x7ffff3e90388) at async.c:111
#19 0x00007ffff78dba1b in uv__async_io (loop=0x7ffff3e90020, w=<optimized out>, events=<optimized out>) at src/unix/async.c:176
#20 0x00007ffff78f8d48 in uv__io_poll (loop=0x7ffff3e90020, timeout=<optimized out>) at src/unix/linux.c:1526
#21 0x00007ffff78e0fbf in uv_run (loop=0x7ffff3e90020, mode=UV_RUN_DEFAULT) at src/unix/core.c:447
#22 0x00007ffff7f6de2c in loop_thread (arg=0x7ffff3e90000) at loop.c:282
#23 0x00007ffff7f847fd in thread_body (wrap=0x7ffff3ee59c0) at thread.c:85
#24 0x00007ffff7f848b6 in isc_thread_main (func=0x7ffff7f6dcb2 <loop_thread>, arg=0x7ffff3e90000) at thread.c:116
#25 0x00007ffff7f6eead in isc_loopmgr_run (loopmgr=0x7ffff3e206c0) at loop.c:454
#26 0x00005555555810e2 in main (argc=5, argv=0x7fffffffe598) at main.c:1574
What is the expected correct behavior?
No crash.
Edited by Mark Andrews