[Dnsmasq-discuss] [BUG] crash in domain-match.c lookup_domain()

Petr Menšík pemensik at redhat.com
Wed Oct 13 14:43:48 UTC 2021


Oh, okay, similar report were reported few hours before this with
subject of "dnsmasq 2.86 crash". Moving discussion into its thread.

On 10/13/21 16:03, Petr Menšík wrote:
>
> I have received already multiple reports [1] of crashes in 2.86
> version. I thought commit de372d6914ae20a1f9997815f258efbf3b14c39b
> might fix that issue, but even more reports arrived with version
> including this commit [2] [3].
>
> I do not have any coredump available for analysis (yet), but bugs
> contain automated backtraces including some variables. It seems
> crop_query operation can overflow to some wrong value. Then qlen gets
> outside of original domain name char buffer and process crashes.
>
> I did not find the failing place yet. I suspect order() function might
> not always enforce qlen > daemon->serverarray[try]->domain_len. But
> without coredump file I am unsure.
>
> Thread 1 (LWP 3842):
> #0  0x0000558a903382be in lookup_domain (domain=0x558a91fd7cd0 "dns.msftncsi.com", flags=128, lowout=0x7fff41395fe8, highout=0x7fff41395fe4) at /usr/src/debug/dnsmasq-2.86-2.fc35.x86_64/src/domain-match.c:234
>         rc = <optimized out>
>         crop_query = <optimized out>
>         nodots = 0
>         qlen = 51543
>         try = <optimized out>
>         high = <optimized out>
>         low = <optimized out>
>         nlow = 0
>         nhigh = 0
>         cp = <optimized out>
>         qdomain = 0x558a91fcb389 <error: Cannot access memory at address 0x558a91fcb389>
> #1  0x0000558a90308a2a in forward_query (udpfd=5, udpaddr=0x7fff41396170, dst_addr=0x7fff41396140, dst_iface=5, header=0x558a91fd9e30, plen=34, limit=0x558a91fda030 "", now=1633667814, forward=0x0, ad_reqd=0, do_bit=0) at /usr/src/debug/dnsmasq-2.86-2.fc35.x86_64/src/forward.c:258
>         flags = 0
>         fwd_flags = 0
>         is_dnssec = 0
>         master = <optimized out>
>         gotname = 128
>         hash = 0x558a91fd9b70
>         oph = 0x0
>         old_src = 0
>         first = 12
>         last = 0
>         start = 0
>         subnet = 0
>         cacheable = 0
>         forwarded = 0
>         edns0_len = 94053643165266
>         pheader = 0x558a91fd9e52 ""
>         ede = -1
>
> Is there any commit after v2.86, which should make this fixed? Does
> anyone else met a crash like this and can provide more debugging?
> Especially useful would be a way to reproduce. It seems like nothing
> very special is required to trigger this bug.
>
> Any thoughts? Fixes maybe?
>
> Cheers,
> Petr
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2009975
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=2012151
> 3. https://bugzilla.redhat.com/show_bug.cgi?id=2012547
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211013/10976a0d/attachment.htm>


More information about the Dnsmasq-discuss mailing list