Simon Kelley <[email protected]> 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.
