Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Nov 2004 10:28:11 -0800
From:      Nate Lawson <nate@root.org>
To:        Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Memory modified after free: Most recently used by acpitask
Message-ID:  <41A4D2BB.7090400@root.org>
In-Reply-To: <1101319662.56574.141.camel@buffy.york.ac.uk>
References:  <1101312453.56574.122.camel@buffy.york.ac.uk> <41A4BB82.2010406@root.org> <1101319662.56574.141.camel@buffy.york.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
Gavin Atkinson wrote:
> On Wed, 2004-11-24 at 16:49, Nate Lawson wrote:
> 
>>Gavin Atkinson wrote:
>>># cp -Rp /usr/* /var/usr
>>>[about 10 minutes later]
>>>Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434
>>>panic: Most recently used by acpitask
>>
>>Unfortunately, the panic message doesn't tell you who modified it since 
>>someone with a stray pointer (say, who allocated/freed it before acpi) 
>>could overwrite it and it was only detected on the next malloc.  The way 
>>I've found these is to boot -d (into ddb) and type "watch 0xc44a8420". 
>>Then hit "c" to continue the boot.  Dump a "tr" any time the watchpoint 
>>triggers and look for suspicious callers.
> 
> 
> Sadly, I suspect it's not going to be that easy.  I've just had another
> panic, same trigger and symptoms but different memory address.
> 
> Memory modified after free 0xc50441c0(28) val=0 @ 0xc50441d4
> panic: Most recently used by acpitask
> 
> cpuid = 0
> KDB: enter: panic
> [thread 100111]
> Stopped at      kdb_enter+0x2c: leave
> 
> I'll try taking the box to top-of-tree current in case it has already
> been fixed - however that will probably have to wait until tomorrow now
> as this machine cannot reboot without physical help.  Surely it seems
> like quite a coincidence that both times it was 20 bytes into memory
> once owned by acpitask, though?

The only coincidence is it's likely the same component causing this 
problem.  acpi is probably only a victim.  FYI, in August I fixed an 
overflow in ATA that had the same symptoms of overwriting an ACPI struct 
(although that doesn't mean this is caused by ATA).

-Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41A4D2BB.7090400>