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

Simon Kelley simon at thekelleys.org.uk
Mon Nov 25 14:19:43 GMT 2013

Many thanks for the thorough analysis. My understanding is that this is 
fixed in


and therefore in 2.68test1 onwards. The Subject of your email implies 
that's not true, or have I misunderstood?

Certainly, the existance of this bug is large part of the motivation for 
the in-progress 2.68 release.



On 25/11/13 12:54, Andrew Childs wrote:
> 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:
> minecraft.cons.org.nz
> 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
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list