Segmentation fault on function showDNSCryptBinds() under certain circumstances

[paddg]

• Program: dnsdist
• Issue type: Bug report

Short description

dnsdist coredumps if I call showDNSCryptBinds(). But only on certain configurations.

Environment

• Operating system: SUSE SLES15
• Software version: dnsdist 1.4.0-beta1
• Software source: self compiled

Steps to reproduce

It happens if I start dnsdist with a empty configuration from command line and call showDNSCryptBinds():

# dnsdist
Listening on 127.0.0.1:53
dnsdist 1.4.0-beta1 comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2
ACL allowing queries from: 192.168.0.0/16, 169.254.0.0/16, fe80::/10, 100.64.0.0/10, 127.0.0.0/8, 10.0.0.0/8, fc00::/7, ::1/128, 172.16.0.0/12
Console ACL allowing connections from: 127.0.0.1/8, ::1/128
No downstream servers defined: all packets will get dropped
Warning, this configuration can use more than 1042 file descriptors, web server and console connections not included, and the current limit is 1024.
You can increase this value by using LimitNOFILE= in the systemd unit file or ulimit.
> Polled security status of version 1.4.0-beta1 at startup, no known issues reported: OK
showDNSCryptBinds()
Speicherzugriffsfehler (Speicherabzug geschrieben)

It also happens with this configuration:

addDOHLocal("127.0.0.1:443", "doh.pem", "doh.key" )
addDNSCryptBind('127.0.0.1:8443', "2.providername", "resolver.cert", "resolver.key")

But it doesn't happen with this configuration:
addDNSCryptBind('127.0.0.1:8443', "2.providername", "resolver.cert", "resolver.key")

Expected behaviour

Not a coredump but something like

showDNSCryptBinds()
#   Address              Provider Name       
0   127.0.0.1:8443       2.providername      
1   127.0.0.1:8443       2.providername

Actual behaviour

Speicherzugriffsfehler (Speicherabzug geschrieben)

[paddg]

Also, why does showDNSCryptBinds() show two binds? I'd expect only one in this case.

[rgacogne]

Also, why does showDNSCryptBinds() show two binds? I'd expect only one in this case.

Right, it's because we are technically listening on UDP and TCP, but I agree it's a bit unexpected. I'll see if we can de-duplicate it nicely, or at least make the UDP/TCP part more obvious.