Using TSIG with multiple threads crashes dnsperf

[kchen]

It appears that using TSIG with multiple threads crashes dnsperf. Using TSIG with -c 2 -T 2 (or larger numbers) triggers the issue, while not using -T does not reproduce the issue.

Here's the backtrace from gdb:

#0  0x00007fa61fc71ca8 in SHA256_Update (c=0x0, data_=0x7fa61d68f6a0, len=32)
    at include/crypto/md32_common.h:135
#1  0x00007fa61fbfd2c1 in HMAC_Final (ctx=0x7fa618001100, 
    md=md@entry=0x7fa61d68f930 "", len=len@entry=0x7fa61d68f724)
    at crypto/hmac/hmac.c:129
#2  0x00007fa61fcebf49 in hmac_final (outsize=<optimized out>, 
    outl=0x7fa61d68f798, out=0x7fa61d68f930 "", vmacctx=0x7fa618001050)
    at providers/implementations/macs/hmac_prov.c:238
#3  hmac_final (vmacctx=0x7fa618001050, out=0x7fa61d68f930 "", 
    outl=0x7fa61d68f798, outsize=<optimized out>)
    at providers/implementations/macs/hmac_prov.c:222
#4  0x00007fa61fbec0cb in evp_mac_final (ctx=0x7fa618001030, 
    xof=<optimized out>, out=0x7fa61d68f930 "", outl=0x7fa61d68f8f8, 
    outsize=64) at crypto/evp/mac_lib.c:168
#5  0x00007fa61fbeb54c in EVP_DigestSignFinal (ctx=0x5643d1d23db0, 
    sigret=sigret@entry=0x7fa61d68f930 "", siglen=siglen@entry=0x7fa61d68f8f8)
    at crypto/evp/m_sigver.c:488
#6  0x00005643d156b7f2 in perf_add_tsig (packet=packet@entry=0x7fa61d68fd20, 
    tsigkey=tsigkey@entry=0x5643d1ce48b0) at tsig.c:305
#7  0x00005643d156838b in perf_dns_buildrequest (record=<optimized out>, 
    qid=<optimized out>, edns=<optimized out>, dnssec=<optimized out>, 
    is_update=<optimized out>, tsigkey=0x5643d1ce48b0, edns_option=0x0, 
    msg=0x7fa61d68fd20) at dns.c:542
#8  0x00005643d15738a4 in do_send (arg=0x7fa61f1e71e8) at dnsperf.c:1073
#9  0x00007fa61f9e5609 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007fa61f7bb533 in clone () from /lib/x86_64-linux-gnu/libc.so.6

It looks like there's a single digest buffer per TSIG key, and probably only one perf_tsigkey_t, which likely explains the crash.

[jelu]

@kchen you're right! thanks for the report. Can you verify that #259 fixes the issue for you?

[kchen]

Yep, it does. Thanks!