interfacemgr.c:326: REQUIRE((__builtin_expect(!!((mgr) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(mgr))->magic == ((('I') << 24 | ('F') << 16 | ('M') << 8 | ('G')))), 1))) failed, back trace

(gdb) bt
#0  0x00007ffff3543860 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff3544ec9 in abort () from /usr/lib/libc.so.6
#2  0x00005555555afd07 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:248
#3  0x00005555557a2cfa in isc_assertion_failed (file=file@entry=0x55555580b3a6 "interfacemgr.c", line=line@entry=326, type=type@entry=isc_assertiontype_require, 
    cond=cond@entry=0x55555580b560 "(__builtin_expect(!!((mgr) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(mgr))->magic == ((('I') << 24 | ('F') << 16 | ('M') << 8 | ('G')))), 1))")
    at assertions.c:49
#4  0x00005555555e6d96 in ns_interfacemgr_getaclenv (mgr=<optimized out>) at interfacemgr.c:326
#5  0x00005555555b160b in get_matching_view (srcaddr=0x7ffff19454c0, destaddr=0x7fffe8040ffc, message=0x7ffff7ed4010, ecs=0x0, sigresult=0x7ffff19453c0, viewp=0x7fffe8040978) at ./server.c:9353
#6  0x00005555555e545a in ns__client_request (task=<optimized out>, event=<optimized out>) at client.c:2634
#7  0x00005555557c84e9 in dispatch (manager=0x7ffff7f8a010) at task.c:1138
#8  run (uap=0x7ffff7f8a010) at task.c:1310
#9  0x00007ffff67c008c in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007ffff3604e7f in clone () from /usr/lib/libc.so.6

This crash seems to be easier to trigger when dnstap is in use, but I
also came across it when using GDB to trace named with dnstap support
compiled away entirely.  Considerable query load seems to be necessary
for triggering the crash.  I was able to semi-reliably reproduce this by
doing the following:

 1. Start dnsperf on the same host.
 2. Start an authoritative-only named in the foreground.
 3. Hit CTRL+C.
 4. Repeat steps 2-3 until a crash happens.

The problem here is that named_g_server->interfacemgr may already be
NULL by the time get_matching_view() gets called from
ns__client_request() if server shutdown is in progress.

The problem was introduced when libns was added (commit 8eb88aafee) and
thus only affects 9.12.0.

Does not look exploitable to me.