[FS#766] Intermittent SIGSEGV crash of dnsmasq-full

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - guidosarducci (guidosarducci) 

Attached to Project - LEDE Project
Summary - Intermittent SIGSEGV crash of dnsmasq-full 
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - High
Priority - Very Low
Reported Version - lede-17.01
Due in Version - Undecided
Due Date - Undecided
Details - I've just noticed seeing the following several times within the last day or so:
[1461327.495159] do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from 00000000
[1461327.504081] epc = 0040f28d in dnsmasq[400000+2c000]
[1461327.509252] ra  = 0040f273 in dnsmasq[400000+2c000]


I'm running the latest LEDE stable, with all updates applied as of 2017-05-05, and have been using DNSSEC for a while:

  * LEDE Reboot 17.01.1 r3316-7eb58cf109
  * D-Link DIR-835 rev. A1
  * dnsmasq-full - 2.76-6

The most recent upgrade in the same time frame was to odhcpd-2017-04-28-9268ca65-1.

After several restarts by procd and subsequent crashes, dnsmasq will be disabled, leaving me without name resolution until I notice and restart manually.

To get a little more info, I rebuilt the stable LEDE and dnsmasq-full with a "-g" CFLAG option. After installing this package, I captured the following crash details:

[1562749.817613] do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from 00000000
[1562749.826522] epc = 0040f295 in dnsmasq[400000+2c000]
[1562749.831681] ra  = 0040f27b in dnsmasq[400000+2c000]


Checking further with gdb yields:
(gdb) info line *0x0040f27b
Line 278 of "forward.c" starts at address 0x40f275 
   and ends at 0x40f281 .

(gdb) info line *0x0040f295
Line 281 of "forward.c" starts at address 0x40f295 
   and ends at 0x40f29b .

And the relevant source (forward.c) looks like:
275               blockdata_retrieve(forward->stash, forward->stash_len, (void *)header);
276               plen = forward->stash_len;
277
278               if (find_pseudoheader(header, plen, NULL, &pheader, &is_sign, NULL) && !is_sign)
279                 PUTSHORT(SAFE_PKTSZ, pheader);
280
281               if (forward->sentto->addr.sa.sa_family == AF_INET)
282                 log_query(F_NOEXTRA | F_DNSSEC | F_IPV4, "retry", (struct all_addr *)&forward->sentto->addr.in.sin_addr, "dnssec");
283     #ifdef HAVE_IPV6
284               else
285                 log_query(F_NOEXTRA | F_DNSSEC | F_IPV6, "retry", (struct all_addr 

Any similar reports from others? I'll keep monitoring in the meantime but this is difficult to reproduce on demand. It *seems* to happen more with web browsing.

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=766