Marcin Jurkowski
2017-09-02 14:33:00 UTC
Hi
I encountered similar problem to the one described in
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q3/011692.html
I'm not using dnseval and crashes seem random.
Like in CVE-2017-13704, it's caused by a memset in rfc1035.c:1228 trying to set
a negative number of bytes. Unfortunately patch 0001-forward.c-fix-CVE-2017-13704.patch
didn't fix this.
I've added some logging and it seems that query length (700) is greater than UDP packet
size (512):
header=0x6c3010, limit=0x6c3210, qlen=700
zero -188 bytes starting at 0x6c32cc
Segfault occurs right after the memory is corrupted by memset:
do_page_fault(): sending SIGSEGV to dnsmasq for invalid write access to 006da000
epc = 7798ded0 in libc.so[7791b000+92000]
ra = 00406e33 in dnsmasq[400000+21000]
kr
I encountered similar problem to the one described in
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q3/011692.html
I'm not using dnseval and crashes seem random.
Like in CVE-2017-13704, it's caused by a memset in rfc1035.c:1228 trying to set
a negative number of bytes. Unfortunately patch 0001-forward.c-fix-CVE-2017-13704.patch
didn't fix this.
I've added some logging and it seems that query length (700) is greater than UDP packet
size (512):
header=0x6c3010, limit=0x6c3210, qlen=700
zero -188 bytes starting at 0x6c32cc
Segfault occurs right after the memory is corrupted by memset:
do_page_fault(): sending SIGSEGV to dnsmasq for invalid write access to 006da000
epc = 7798ded0 in libc.so[7791b000+92000]
ra = 00406e33 in dnsmasq[400000+21000]
kr