[Dnsmasq-discuss] crash on double free

[Ferenc Wagner]

Simon Kelley <simon at thekelleys.org.uk> writes:

> On 15/09/10 12:07, Ferenc Wagner wrote:
>
>> However, I also got a different crash with the original binary.  I hope
>> it's a different realisation of the same problem, can you confirm?
>>
>> (gdb) bt
>> #0  0xb7599d5a in memcpy () from /lib/i686/cmov/libc.so.6
>> #1  0x080623d0 in add_extradata_data (lease=0xb74f6fac,
>>      data=0xb7182b68 "Linux ipconfigÿ\001þ\006\004\nú\001þ\017\talma.grid\f\02152-54-00-12-34-56\021\020/var/lib/nfsrootÿ", len=3071814504, delim=0) at rfc2131.c:1533
>> #2  0x0806242c in add_extradata_opt (lease=0xb74f6fac, opt=<value optimized out>) at rfc2131.c:1555
>> #3  0x08067040 in dhcp_reply (context=0xb74bafc4, iface_name=0xbfda1124 "br-alma-g", int_index=10,
>>      sz=283, now=1284499746, unicast_dest=0, is_inform=0xbfda11a4, pxe=0) at rfc2131.c:1240
>> #4  0x0805fb3e in dhcp_packet (now=1284499746, pxe_fd=0) at dhcp.c:301
>> #5  0x0805d7de in main (argc=Cannot access memory at address 0x3
>> ) at dnsmasq.c:688
>> (gdb) up
>> #1  0x080623d0 in add_extradata_data (lease=0xb74f6fac,
>>      data=0xb7182b68 "Linux ipconfigÿ\001þ\006\004\nú\001þ\017\talma.grid\f\02152-54-00-12-34-56\021\020/var/lib/nfsrootÿ", len=3071814504, delim=0) at rfc2131.c:1533
>> 1533	    memcpy(lease->extradata + lease->extradata_len, data, len);
>>
>> The passed-in value of "len" is obviously bogus here.
>>
>> (gdb) p lease->extradata
>> $1 = (unsigned char *) 0xb7184f8c "Linux ipconfig"
>> (gdb) p lease->extradata_len
>> $2 = 0
>> (gdb) p data
>> $3 = (
>>      unsigned char *) 0xb7182b68 "Linux ipconfigÿ\001þ\006\004\nú\001þ\017\talma.grid\f\02152-54-00-12-34-56\021\020/var/lib/nfsrootÿ"
>
> I can't see any other reason for this problem, I'm pretty sure it's
> down to heap corruption from an earlier double-free.

It's a rather narrow chance, as I was running under electric fence...

>> I'm continuing testing the fix.  It usually took me tens of minutes to
>> reproduce the crash, but with the change it already survived more than
>> an hour.  Unfortunately, it isn't fully automatic (because of other bugs
>> in other software).
>
> To trigger this bug, there needs to be a dhcp-script, obviously. But
> also the rate of DHCP transactions needs to be fast enough and/or the
> script needs to be slow enough so that a second DHCP transaction
> happens on a lease before the first one has been sent to the
> DHCP-script. This is pretty rare, hence no-one has seen this bug, as
> far as I know, even though it has been lurking for some time (years).

Well, this doesn't fully match my test setup, which contained a single
netbooted Linux continuously rebooting in Qemu.  The exotic part is that
the PXE ROM used the network interface natively, while the Linux system
with an added 802.1q tag.  So a single lease was ping-ponging between
two different subnets.
-- 
Cheers,
Feri.