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: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
