[Dnsmasq-discuss] crash on double free

Simon Kelley simon at thekelleys.org.uk
Mon Sep 20 17:21:23 BST 2010


Ferenc Wagner wrote:
> 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...

It was late..... I'll try again :-)

At the point of the crash, 0xb7184f8c had already been freed and
therefore mapped out by efence. Hence when 0xb7184f8c  gets deferenced
by memcpy, it segfaults. This is consistent with the known and fixed bug.

The value of "len" must be a optimisation artifact, there is no way that
add_extradata_opt() could generate  that value.


> 
>>> 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.

How much work was you dhcp-script doing. By coincidence I had another
report of this bug yesterday which triggered only when the DHCP
transaction rate is high.

Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list