> I wonder how many security holes, both those known and as yet unrevealed > or unknown, would not be of any exploit value if in all security related > libraries and applications the routine to free allocated memory > allocation closest to the user app/library set the newly free memory to > a known pattern or something from /dev/random before returning. And, > similarly, a compiler option causing function returns using more than a > few dozen bytes of stack space to erase the newly freed stack region I'm probably being really dense here, and realise I can't delete this post once sent! But.... Once memory has been freed, I thought any attempt by a user process to access it would cause a SIGSEV. I thought the issue was with programs that inadvertantly expose (either to read or write) other parts of their active memory. Of course, if a process rolls it's own in-process implementation of malloc/free, then this point is moot, but once you free memory back to the system, isn't in no longer accessable anyway? Cheers, Jamie _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"