Date: Thu, 18 Sep 1997 20:51:13 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Nate Williams <nate@mt.sri.com> Cc: Graham Wheeler <gram@cdsec.com>, hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <10897.874608673@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 18 Sep 1997 12:11:25 MDT." <199709181811.MAA13376@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199709181811.MAA13376@rocky.mt.sri.com>, Nate Williams writes: >Poul-Henning Kamp writes: >> In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: >> >> >i.e. the size is stored both immediately preceding and immediately >> >following the useable space. As part of the consistency checking, >> >these two sizes are compared and should match. This should catch almost >> >all small overruns or underruns, and abort the process. So this >> >malloc should be less tolerant of bugs in my code than pkhmalloc is, >> >rather than more tolerant, >> >> again: depends. > >True, but I think Graham's arguement puts the ball in your court. Yes, >it's *possible* that a bug in his code exists, but given that his other >malloc has debugging capabilities built-in, one could argue that the >burden of proof is now on PHK-malloc. No. Unless the other implementation has the strength of Purify, this argument doesn't hold. I'm actually currently leaning to the opinion that phkmalloc is better at exposing errors than this other malloc is. :-) Remember that many checks which are considered "debugging" in other mallocs are standard in phkmalloc. If you don't trust me, try to grep for malloc in the commit logs to see what it has already found ;-) Anyway, if you think so: do like so many others have done, look at the source for phkmalloc.c and try to spot the error. I can't. In this particular case phkmalloc is vulnerable because it uses small allocations to track the freelist: free(16 bytes allocation) /* phkmalloc flips the bitmap for this "chunk" */ free(some allocation) /* this results in an entire page being added to the freelist, consequently a freeheader is allocated the above 16 byte chunk is used in this case */ write to the 16 byte allocation above free or alloc something /* phkmallocs internal data is corrupt and we spin */ >> This is about the only way you could get it to loop I think. That means >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > >Yikes, this would be 'Hard to Do', even by design (ie; self-modifying >code). But, stranger things have happened, especially with dealing with >malloc/free. No, all you have to do is to make each allocation have it's own set of pages, munmap them when free is called and never use those pages again. You run out of address space really fast, and it is slow, but it works. >I could understand that this could be a reason where phkmalloc would >fail, and another debug library wouldn't. However, if you modified >PHK-malloc's storage capability (say, have it allocate 2X normal memory), the >problem should go away, since you'd be modifying something other than >the 'prev/next' pointer variable. In phkmalloc there is no prev/next pointer except for the ones that keep track of the freelist. (Read the paper in src/share/papers/.../malloc) >> This would indicate a bug of the class where memory is written to after >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > >This is a 'hard problem'. Not really, there is a simple way to find it I belive. Hack phkmalloc the following way: Add a nontrivial checksum field to the freechunk structure. Check before use, and update it after changes. Should nail it in no time. >Graham, does your software run on a Solaris or HP/UX box? If so, you >may consider getting an evaluation copy of Purify and running it against >your code. IMHO, Purify is the *best* single-tool for pointing out these >kinds of errors, aside from good programming practices. I find it even >more useful than a debugger for 'hard to find' errors, although when >coupled with a debugger it's usefulness is second to none. Indeed. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10897.874608673>