Inaccuracy
"The idea is to leave hostile code in memory following the crash, at a location where it is subsequently executed once a system is restarted."
Thats not a buffer overflow, and heres why;
Memory isn't retained in any useful way after a "system is restarted", memory is volatile and doesn't remain in use after a reboot, and of course all allocations are new and software should never point to the same exact location in the chips after being allocated a second time, that and the natural state of decay of memory during a reboot would make this idea so very flawed it shouldn't have been published.
So what is a buffer overflow? Well as you don't seem to have a grasp on this let me explain...
The trick is to overflow a buffer (obviously), typically a string without correct bounds checking, so for instance if I took;
char bleh[5]; //allocate a string of 5 bytes max length
then did;
strcpy(bleh, "THIS IS A LOT LONGER THAN THE 5 BYTES I ALLOCATED");
I would be over-writing some part of memory as strcpy doesn't check the size of the buffer its copying into. Typically the stack is modified, munging the heap is a lot harder as they heap is far bigger.
Now if I for instance copied into that string enough data to reach the eip register (extended instruction pointer) I would be able to specify an address for the function call that hasn't checked the buffer sizes to return to, which would have to be somewhere inside of my buffer because thats the part of memory I can control. So my eip overwrite needs to have a known location to return to, this is hard to get right, so i'd fill some NOP (no operation) instructions in, this is called a NOP sled, and as long as you point the execution back to somewhere in that NOP sled you should be able to execute a shell code, or egg after all of those NOP instructions have been processed, that egg can create a nice little shell prompt, or open a bind port, or any number of things which will allow more access to the system.
Maybe you need some more education on how these things work, there's a detailed article, credited as probably the most important free publication on buffer overflows ever to have been written.
You'll find this article at this address, http://www.phrack.org/archives/49/P49-14