[TUHS] Buffer overflow found/fixed in v4 tape ;)

[Dan Cross via TUHS]

On Mon, Jan 5, 2026 at 10:51 AM Warner Losh via TUHS <tuhs at tuhs.org> wrote:
> On Mon, Jan 5, 2026 at 8:41 AM Paul Winalski via TUHS <tuhs at tuhs.org> wrote:
> > On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS <tuhs at tuhs.org> wrote:
> > > Overflowable buffers were common in those days. It was all too easy
> > > when programming to shrug one's shoulders and opine that nobody would
> > > ever want to input a 200-character line, say, so why bother writing
> > > the extra code to catch it? We did gradually learn that automatically
> > > generated input lines--particularly lines of code--could be much
> > > longer than any person would write, so buffer overflows that actually
> > > happened gradually got fixed.
> > >
> > There was another consideration.  Machines in those days were slow and had
> > tiny memory capacity.  Was it really worth wasting the extra memory space
> > and CPU time for buffer overflow checking in cases where it was extremely
> > unlikely to occur?
>
> Yes. It's hard to believe today, but in the pre-morris-worm era, buffer
> overflows only mattered if they crashed the program and even then
> they were often ignored due to execution time and/or code bloat
> considerations. One of the trade offs we were taught in my OS class
> was when to check: Crashing the kernel is bad, so check there,
> but make the check as cheap as you can.

Indeed.  My invariant has always been, "user programs should not be
able to (directly) crash the kernel." I say, "directly" because
there's an argument that some action taken by a user program might
tickle a different problem (say, a faulty hardware device) that causes
a crash and there may be little one can do about it, but it should
never be the case that just giving a bad pointer or number to the
kernel should result in a panic.

> In userland, just let the program crash: that's  zero cost feedback.
> Almost[*] everybody was going around, like in the princess bride,
> saying problems from this attitude were "Inconceivable" but the
> morris worm was the "You keep on using that word, I don't think it
> means what you think it means" moment that changed everything.

Funny, I just watched that movie with my kids over the weekend....

But I'm not sure that was actually the turning point.  I think it was
the, "smashing the stack for fun and profit" paper that really got
things going with respect to people being serious about buffer
overruns and the like, at least locally.  I rather got the impression
that the Morris worm was seen as an interesting example of a category
of problem, but mostly treated as a one-off.

> [*] We all know the classic papers that were ignored pre-worm...

I'm actually afraid that I do not, but it sounds like an interesting
list. Any pointers to the top few?

        - Dan C.