dnsdist: sigabrt on Fedora 28

[rubenk]

• Program: dnsdist
• Issue type: Bug

Short description

Environment

• Operating system: Fedora 28
• Software version: dnsdist-1.3.0-1.fc28.x86_64.rpm
• Software source: https://koji.fedoraproject.org/koji/buildinfo?buildID=1087802

Steps to reproduce

(Copied from https://bodhi.fedoraproject.org/updates/FEDORA-2018-908399dcfc:)

$ openssl req -newkey rsa:2048 -nodes -keyout dnsdist.key -x509 -days 365 -out dnsdist.pem
$ openssl rsa -pubout -outform der -in dnsdist.key | openssl dgst -binary -sha256 | openssl base64  # for use in eg stubby

$ cat /etc/dnsdist/dnsdist.conf
addLocal("127.0.99.1")
addTLSLocal('127.0.99.1', '/etc/dnsdist/dnsdist.pem', '/etc/dnsdist/dnsdist.key')
newServer({address='8.8.8.8:53'})
$

$ cat /etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 128

edns_client_subnet_private: 1

round_robin_upstreams: 1

idle_timeout: 10000

listen_addresses:
  - 127.0.0.1
  - 0::1

upstream_recursive_servers:
  - address_data: 127.0.99.1
    tls_auth_name: "CN-entered-when-generating-cert"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: base64-value-from-second-openssl-cmd

dig @127.0.0.1 example.com

Expected behaviour

dig returning a response

Actual behaviour

dnsdist crashes with sigabrt:

> Got TCP connection from 127.0.0.1:51450
/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator<char>; std::vector<_Tp, _Alloc>::reference = char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

Thread 8 "dnsdist" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff0e95700 (LWP 21625)]
0x00007ffff5964f2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libblkid-2.32-2.fc28.x86_64 libcap-2.25-9.fc28.x86_64 libedit-3.1-23.20170329cvs.fc28.x86_64 libgcc-8.1.1-1.fc28.x86_64 libgcrypt-1.8.2-2.fc28.x86_64 libgpg-error-1.29-1.fc28.x86_64 libmount-2.32-2.fc28.x86_64 libselinux-2.7-13.fc28.x86_64 libsodium-1.0.16-4.fc28.x86_64 libstdc++-8.1.1-1.fc28.x86_64 libuuid-2.32-2.fc28.x86_64 luajit-2.1.0-0.7beta3.fc28.x86_64 lz4-libs-1.8.1.2-4.fc28.x86_64 ncurses-libs-6.1-5.20180224.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 pcre2-10.31-4.fc28.x86_64 protobuf-3.5.0-4.fc28.x86_64 sssd-client-1.16.1-9.fc28.x86_64 systemd-libs-238-8.git0e0aa59.fc28.x86_64 xz-libs-5.2.4-2.fc28.x86_64 zlib-1.2.11-8.fc28.x86_64
(gdb) thread apply all bt
Thread 8 (Thread 0x7ffff0e95700 (LWP 21625)):
#0  0x00007ffff5964f2b in raise () from /lib64/libc.so.6
#1  0x00007ffff594f561 in abort () from /lib64/libc.so.6
#2  0x00005555555f38d8 in std::__replacement_assert (__file=__file@entry=0x5555558091c8 "/usr/include/c++/8/bits/stl_vector.h", __line=__line@entry=932,
    __function=__function@entry=0x55555586e180 <std::vector<char, std::allocator<char> >::operator[](unsigned long)::__PRETTY_FUNCTION__> "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator<char>; std::vector<_Tp, _Alloc>::reference = cha"...,
    __condition=__condition@entry=0x555555809198 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#3  0x00005555557a54bd in std::vector<char, std::allocator<char> >::operator[] (__n=0, this=<synthetic pointer>) at dnsdist-tcp.cc:320
#4  tcpClientThread(int) () at dnsdist-tcp.cc:320
#5  0x00007ffff6358513 in ?? () from /lib64/libstdc++.so.6
#6  0x00007ffff6632594 in start_thread () from /lib64/libpthread.so.0
#7  0x00007ffff5a2800f in clone () from /lib64/libc.so.6

[rubenk]

This is probably similar to #6669

[hlindqvist]

When looking at the backtrace (ie https://pastebin.com/r7jgfPNx), I realized the same happens for regular queries over TCP.

Ie dig @dnsdist example.com +tcp also triggers the same crash.