Let's say I have an empty glass (memory allocation). I know ahead of time that the maximum capacity of that glass is 8 ounces. A buffer overflow is what happens when I overfill that glass. If the amount of water in the glass stays less than 8 ounces, no problem. If it overfills, I don't quite know where it'll go. It might get into something it shouldn't be in (security, program instability, etc).
And "glass model" is still fine anyway. If you know that glass stands on the piece of sodium you know there'll be problems ;)
The “glass over a piece of sodium” analogy is flawed too. It makes it sound like the program has to be special and dangerous for a buffer overflow to have dramatic consequences. It doesn't. It may be an ordinary program written to fulfill an ordinary task, and contain buffer overflows that are completely exploitable.
You've basically said "a buffer overflow is what happens when your buffer overflows". It doesn't explain how memory outside the buffer can be overwritten when it overflows.
Now imagine buying 10 gallons of coolant and repeating this experiment until you have a very good idea of exactly how to pour the coolant to make it land on the timing belt, or in other places, and that is a way to think about what happens when a hacker is exploiting a buffer overflow.
:)
Next: 'Fatal Bus Error'. Car analogy please!
Not a hardware guy but let's see, imagine being in 6th in a six speed, and trying to shift up. That noise you just heard? That's your gear shifter issuing back a 'bus error' that you have no more gears to use.
That's all I got ;)