Never trust a git commit which happened in the early hours :)

Thanks for a second excellent bug report. This was much easier to find.

I've committed the fix to git.

I'll deal with Petr's patch tomorrow and then tag 2.77rc2

Cheers,

Simon.


On 09/05/17 09:33, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 09/05/17 01:39, Simon Kelley wrote:
>> That was a horrible one.
>>
>> Fix committed, and an optimistic 2.77rc1 tag added.
> 
> Sadly a tad optimistic.  From the original reporter, and I can confirm
> 'domain-needed' is the crash enabling option:
> 
> Sorry!
> 
> Looking forward to the final release following the rc2 :-)
> 
> Cheers,
> 
> Kevin
> 
> 
> 
>> I saw the update from Simon Kelley (thank you!) on the Dnsmasq-discuss
>> mailing list and built an updated LEDE dnsmasq-2.77rc1 package to
>> test. (see required patch attached)
> 
> The prior minimal test-case passed, but the original production config
> file now creates a horrible SIGSEGV crash-loop (log attached):
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.539480]
> do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from
> 00000000
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.548375] epc =
> 0040e79b in dnsmasq[400000+2d000]
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.553564] ra  =
> 0040e773 in dnsmasq[400000+2d000]
> 
> 
> Stack trace indicates something to do with logging:
> (gdb) core-file dnsmasq.18906.11.1494309586.core
> [New LWP 18906]
> ...
> Core was generated by `dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c
> --no-daemon'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x0040e79b in search_servers (now=now@entry=1494309586,
>     addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
>     type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
>     norebind=norebind@entry=0x0) at forward.c:222
> 222           log_query(logflags | flags | F_CONFIG | F_FORWARD,
> qdomain, *addrpp, NULL);
> (gdb) bt
> #0  0x0040e79b in search_servers (now=now@entry=1494309586,
>     addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
>     type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
>     norebind=norebind@entry=0x0) at forward.c:222
> #1  0x00410759 in reply_query (fd=, family=,
>     now=now@entry=1494309586) at forward.c:938
> #2  0x004127dd in check_dns_listeners (now=now@entry=1494309586)
>     at dnsmasq.c:1560
> #3  0x004047db in main (argc=, argv=)
>     at dnsmasq.c:1044
> (gdb) print logflags
> $1 = 32800
> (gdb) print flags
> $2 =
> (gdb) print *qdomain
> value has been optimized out
> (gdb) print addrpp
> $3 = (struct all_addr **) 0x0
> (gdb)
> 
> This turns out to be easy to reproduce. Simply add domain-needed to the
> prior standalone config file.
> Then trigger the crash from a client with:
> $ nslookup -port=55553 google.com 192.168.1.1
> ;; connection timed out; no servers could be reached
> 
> I attached all the relevant logs, configs and patches.
> 
> 
> ----------
> 
> One or more files have been attached.
> 
> More information can be found at the following URL:
> https://bugs.lede-project.org/index.php?do=details&task_id=766#comment2589
>> I really hope to get out a 2.77 release soon.
>>
>>
>> Cheers,
>>
>> Simon.
>>
> 
> 
> 
> 
> 
> 
> 
> 
>> On 08/05/17 13:30, Kevin Darbyshire-Bryant wrote:
>>> Hi Simon,
>>>
>>> Got a report in LEDE land about a SIGSEGV issue,  I'm able to replicate
>>> easily as described.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>>
>>> Kevin
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: [FS#766] Intermittent SIGSEGV crash of dnsmasq-full
>>> Date: Mon, 08 May 2017 05:57:18 +0000
>>> From: LEDE Bugs <lede-b...@lists.infradead.org>
>>> Reply-To: lede-b...@lists.infradead.org
>>> To: lede-b...@lists.infradead.org
>>>
>>> The following task has a new comment added:
>>>
>>> FS#766 - Intermittent SIGSEGV crash of dnsmasq-full User who did this -
>>> guidosarducci (guidosarducci)
>>>
>>> ----------
>>> After a little more investigation, this is definitely a bug that also
>>> exists in the latest lede/master which uses dnsmasq-2.77test5. It is
>>> easily triggered via a common mozilla DNS query, and appears related to
>>> using split DNS and DNSSEC.
>>>
>>> A minimal, standalone dnsmasq.conf that is vulnerable:
>>> listen-address=192.168.1.1
>>> port=55553
>>> bind-interfaces
>>> no-daemon
>>> no-hosts
>>> no-resolv
>>> log-queries=extra
>>> server=8.8.8.8
>>> server=/cloudfront.net/50.22.147.234
>>> dnssec
>>> dnssec-check-unsigned
>>> trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
>>>
>>>
>>> trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
>>>
>>>
>>>
>>>
>>> Removing either of these config lines results in no SIGSEGV:
>>> server=/cloudfront.net/50.22.147.234
>>> dnssec-check-unsigned
>>>
>>> The bug can be triggered from a DNS client simply (e.g.a blank Firefox
>>> page!):
>>> ubuntu$ nslookup -port=55553 tiles-cloudfront.cdn.mozilla.net
>>> 192.168.1.1
>>> ;; Question section mismatch: got cloudfront.net/DS/IN
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> I also captured a dnsmasq core file from my router and ran it through
>>> gdb:
>>> ubuntu$
>>> ./staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-gdb
>>>
>>> -d
>>> ./build_dir/target-mips_24kc_musl-1.1.16/dnsmasq-full/dnsmasq-2.77test5/src/
>>>
>>> -n
>>> ./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq
>>> dnsmasq.757.11.1494218146.core
>>> GNU gdb (GDB) 7.12
>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later ...
>>> Reading symbols from
>>> ./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq...done.
>>>
>>>
>>> [New LWP 757]
>>> ...
>>> Core was generated by `dnsmasq -C crash-dnsmasq.conf'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
>>>     dst_addr=, dst_iface=dst_iface@entry=0,
>>>     header=header@entry=0x7c8010, plen=43, plen@entry=50,
>>>     now=now@entry=1494218146, forward=0x77cabd90,
>>> ad_reqd=ad_reqd@entry=0,
>>>     do_bit=do_bit@entry=0) at forward.c:281
>>> 281               if (forward->sentto->addr.sa.sa_family == AF_INET)
>>> (gdb) bt
>>> #0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
>>>     dst_addr=, dst_iface=dst_iface@entry=0,
>>>     header=header@entry=0x7c8010, plen=43, plen@entry=50,
>>>     now=now@entry=1494218146, forward=0x77cabd90,
>>> ad_reqd=ad_reqd@entry=0,
>>>     do_bit=do_bit@entry=0) at forward.c:281
>>> #1  0x00410275 in receive_query (listen=listen@entry=0x77cbffe0,
>>>     now=now@entry=1494218146) at forward.c:1443
>>> #2  0x00412825 in check_dns_listeners (now=now@entry=1494218146)
>>>     at dnsmasq.c:1565
>>> #3  0x004047db in main (argc=, argv=)
>>>     at dnsmasq.c:1044
>>> (gdb)
>>>
>>>
>>> The dnsmasq config file, log file, and client log are attached. I'm not
>>> sure I can go any further, so would appreciate the dnsmasq package
>>> maintainer taking a look and advising.
>>>
>>> Thanks!
>>> ----------
>>>
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to