[Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb

[Simon Kelley]

On 18/09/18 11:28, Kristian Evensen wrote:
> Hello,
> 
> I recently updated one of my x86-based OpenWRT-routers to the latest
> nightly, which bumped dnsmasq to 2.80test6. After the update, I see
> that dnsmasq sometimes enters a crash loop. The crash occurs right
> startup (SIGSEV), and the backtrace, looks as follows:
> 
> 0x0000000000406a78 in make_non_terminals
> (source=source at entry=0x7ffff7ffefa0) at cache.c:1437
> 1437 cache.c: No such file or directory.
> (gdb) bt
> #0  0x0000000000406a78 in make_non_terminals
> (source=source at entry=0x7ffff7ffefa0) at cache.c:1437
> #1  0x0000000000407192 in add_hosts_entry (cache=0x7ffff7ffefa0,
> addr=0x7fffffffea28, addrlen=4, index=2, rhash=<optimized out>,
> hashsz=<optimized out>) at cache.c:911
> #2  0x00000000004074e1 in read_hostsfile
> (filename=filename at entry=0x425a8a "/etc/hosts", index=index at entry=2,
> cache_size=cache_size at entry=150, rhash=0x635020,
> hashsz=hashsz at entry=641) at cache.c:1040
> #3  0x0000000000407810 in cache_reload () at cache.c:1185
> #4  0x0000000000418037 in clear_cache_and_reload
> (now=now at entry=1537265437) at dnsmasq.c:1547
> #5  0x0000000000405ec3 in async_event (now=1537265437, pipe=15) at
> dnsmasq.c:1310
> #6  main (argc=<optimized out>, argv=<optimized out>) at dnsmasq.c:1077
> 
> My current work-around is to check if crecp is NULL and then return
> from make_non_terminals(). However, I don't know the code well enough
> to know if this change will break anything else (though everything
> seems to work fine).
> 
> There is nothing special with my hosts file, it looks as follows:
> 
> 127.0.0.1 localhost
> 
> ::1     localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> 192.168.5.1 myrouter.lan
> 
> If checking for NULL is acceptable, I will be more than happy to send
> my patch. If not, I wonder if anyone has any hints on how to proceed
> to solve this issue?
> 

Thanks for the report. The obvious explanation is that whine_malloc() is
returning NULL, and the code should handle that. whine_malloc only
returns NULL if the system cannot allocate any more memory, which is
possible, but unlikely. Is your router very short on memory?
whine_malloc() is just a wrapper around malloc that logs an error if the
malloc fails (hence the name) Are you seeing messages like

failed to allocate %d bytes

just before the crashes? That would make me more comfortable that we
understand the problem. I think the best solution is to wrap all of

      *crecp = *source;
      crecp->flags &= ~(F_IPV4 | F_IPV6 | F_CNAME | F_DNSKEY | F_DS |
F_REVERSE);
      crecp->flags |= F_NAMEP;
      crecp->name.namep = name;

      cache_hash(crecp);

with

if (crecp)
{
}


and I'll commit that to the git repo now.

Cheers,

Simon