[Dnsmasq-discuss] CNAME related segfault in v2.67 onwards

[Andrew Childs]

Hi,

I recently upgraded to v2.67 (on FreeBSD, built with “gmake clean all-i18n CFLAGS=-g") and found dnsmasq was frequently crashing when queried for a particular cname with the following stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000403804 in cache_unlink (crecp=0x80146f580) at cache.c:221
221         crecp->prev->next = crecp->next;
(gdb) bt
#0  0x0000000000403804 in cache_unlink (crecp=0x80146f580) at cache.c:221
#1  0x00000000004042bc in cache_find_by_name (crecp=0x80146f580, name=0x801409100 "a", now=1385382757, prot=2176) at cache.c:568
#2  0x000000000040c005 in answer_request (header=0x80142d000, limit=0x80142d200 "", qlen=19, local_addr=..., local_netmask=..., now=1385382757) at rfc1035.c:1765
#3  0x000000000041b2b1 in receive_query (listen=0x801407100, now=1385382757) at forward.c:893
#4  0x0000000000421a36 in check_dns_listeners (set=0x7fffffffd4c0, now=1385382757) at dnsmasq.c:1369
#5  0x00000000004207d6 in main (argc=4, argv=0x7fffffffd718) at dnsmasq.c:898

With the configuration:

    no-hosts
    addn-hosts=dnsmasq-hosts
    cname=a,b

Where dnsmasq-hosts has the following contents:

    192.168.1.1 minecraft.cons.org.nz
    192.168.1.2 b

Using git bisect it looks like this was introduced in d56a604a9600c08d4a863527d549713c07f0186d.

As far as I understand it’s not valid to call cache_unlink on an entry added by the configuration files, and indeed the next and prev pointers look like uninitialised memory (possibly even part of the word “minecraft”). I think the crash is being caused by a disagreement of which flags designate a configuration based cache entry. add_hosts_cname sets the flag F_CONFIG (changed from F_HOSTS by d56a604), while cache_find_by_name checks for F_HOSTS | F_DHCP when deciding whether or not to call cache_unlink.

Changing the two occurrences of testing F_HOSTS | F_DHCP to testing F_CONFIG in cache_find_by_name allows me to successfully resolve my test case, but I haven’t explored enough to know which location isn’t using the correct flags.

Regards,
Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4133 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20131126/0f62c832/attachment.bin>