Many thanks, it was useful.

I think that

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=04db1483d1a86823240d986e10cfdbf75e1b9954

should fix this, but I've not been able to reproduce the problem here,
so the fix is theoretical at this point. If you or your original
reporter could try it out, that would be great.


Cheers.


Simon.


On 09/10/2019 19:55, Dominik DL6ER wrote:
> FYI: Shared the requested PCAP file directly with Simon as it contains 
> sensitive information (browsing behavior).
> 
> Best,
> Dominik
> 
> On Mon, 2019-10-07 at 17:58 +0100, Simon Kelley wrote:
>> On 05/10/2019 11:22, Dominik wrote:
>>> Hey all,
>>>
>>> I'm reporting a bug on behold of another user that does not want to
>>> contact this mailing list himself.
>>>
>>> Short summary: With DNSSEC enabled, the user sees a crash when dnsmasq
>>> wants to retry a query after the upstream DNS server responded before
>>> with "REFUSED DNSKEY". At least this is my theory so far.
>>>
>>> This crash happens with dnsmasq v2.80.
>>>
>>> The backtrace shows that the error is encountered at
>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=3dd863335b1320477c56b7c50112bfe241cfd574;hb=91421cb7575df7bb211dacc30dc7c7c715c38299#l303
>>>>> if (forward->sentto->addr.sa.sa_family == AF_INET)
>>>
>>> With gdb, we saw that the crash happens when dnsmasq tries to access
>>> forward->sentto->...:
>>> (gdb) p forward
>>> $1 = (struct frec *) 0x5569e433b0e0
>>> (gdb) p forward->sentto
>>> $2 = (struct server *) 0x0
>>> (gdb) p forward->sentto->addr
>>> Cannot access memory at address 0x0
>>> (gdb) p forward->sentto->addr.sa
>>> Cannot access memory at address 0x0
>>> (gdb) p forward->sentto->addr.sa.sa_family
>>> Cannot access memory at address 0x0
>>>
>>> Further details can be found in the issue ticket below.
>>> I'll man-in-the-middle things back and forth if necessary.
>>> https://github.com/pi-hole/FTL/issues/645
>>>
>>
>> Thanks for this. There's lots of useful information already.
>>
>> I think that the problem may be related to having both 127.0.2.1 and ::1
>> as servers: The REFUSED reply from one causes dnsmasq to retry the query
>> on the other and somewhere in that process, internal datastructures are
>> mangled.
>>
>> What would be really useful would be to see more history to the packet
>> dumps, and preferably a copy of the pcap file. Could you help get those?
>>
>> Cheers,
>>
>> Simon.
>>
>>
>> _______________________________________________
>> 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

Reply via email to