[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

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=7b174c250df2bc97b503fd03b9e473998676b1a6

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.


Cheers,

Simon.





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:
>
>      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
>
>
>
>
> _______________________________________________
> 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