[Dnsmasq-discuss] CNAME related segfault in v2.67 onwards
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
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:
> 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:
> 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.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss