The point the article misses is that the original yacc contains a similar problem, which lived on through many versions, including berkeley yacc. See for more details: http://undeadly.org/cgi?action=article&sid=20080708155228

Problem with this narrative: the bug was found in OpenBSD's implementation of yacc, which is actually byacc (Berkeley yacc), a clone of the original AT&T yacc. byacc was written in 1990 according to the wikipedia article <http://en.wikipedia.org/wiki/Byacc>.

See <http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yacc/skeleton.c> and <http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yacc/ACKNOWLEDGEMENTS?rev=1.1.1.1>

So it's a venerable 18-year-old bug being fixed, not a hoary 33-year-old bug.

A commenter mentioned that the problem lies in the parser created by yacc and could therefore impact the kernel. While it could be used as a meta-exploit (a la Thompson's "Reflections on Trusting Trust") it's highly unlikely that every tool in the build chain would be affected by this error. Also, it's important to remember:

1) Most modern UNIXes do not use yacc in their compilers. They either use the GNU Bison equivalent, Berkeley's clean-room implementation byacc, or forego LR parsing for handcrafted recursive-descent parsers. I would be surprised if anything outside of the original awk and /usr/ucb/cc still used the original yacc, considering the speed improvements of bison and byacc.

2) The yacc-generated parser is not in the kernel itself; it is in the original 'cc' compiler. While it is possible that the parser overflow could result in erroneous code generation, it's much more likely that the compiler would simply crash.

3) If it did produce bad kernel code, you would think that the kernel failure would have been detected far earlier than today.

4) It's a real stab in the eye for the "many eyes make clean code" hypothesis of the free software advocates, isn't it?

To correct some (weird/mad) misconceptions in some of the comments I'm going to claim to know the following:

1. Its quite possible to have a bug in the source code which depends on the system architecture and how various values resolve to real underlying storage sizes. A 64-bit architecture might use a larger "integer" for example. So then things would take more space on certain machines. 
2. Sometimes these assumed sizes change suddenly over the years. Problems of this type made Unicode so hard as suddenly a char-acter became 16-bit rather than 8-bit value. 
3. I suspect in this case that the malloc in question was not consistent in calculating the size of the storage it wanted. So it (say) assumed the size of a char, integer, date, or struct, etc. This assumption failed on the Sparc 64 - so the bug was coded in the 1970s but was only recently activated. 
4. In a way this is like the real Y2K bugs. Many had been coded years before but related to years > 2000; things that produce output like 19108 for the 4 digit year. 
5. Oh yeah. And YACC was pretty ubiquitous - though not as much as sed or standard liraries - almost everything with a parsing function used it.

Not only is it a Unix bug, it's a serious Unix bug. YACC builds the compiler and the compiler builds every other part of Unix, including the kernel. But YACC was generating bad code, so the compiler had a buffer overflow bug. Potentially that compiler bug could lead it in turn to generate bad code. So the result might have been bad code anywhere in Unix or in Unix apps since 1975!

Anyway, YACC was included as a standard utility when I was utilities manager of a V7-era Unix product. We had to include it because several popular Unix apps needed it to build their parsers. It was as much a part of Unix as fsck or sed.

They should really have started with 2030 and used negative numbers... at least that way 32bit would have lasted until 2085.. but sure by then there will be no need for humans let alone unix...


And we love you Dimitris. Can we call you "Dim"? (btw - you might want to Google "unix epoch".)

Wrong on multiple counts:

1) this bug has nothing to do with dates

2) Unix systems count time from Jan. 1, 1970, not Jan. 1, 1975

3) complaining they didn't use 64 bits instead of 32 in 1970, when memory was expensive enough no one wasted 4 bytes unnecessarily, and no one foresaw that a research system designed as an inexpensive copy of Multics would still be around decades later

4) they can change the date representation to be unsigned and then the "Y2K38" bug won't hit until after 2100. I'll be dead then, so I'm not going to worry about it!

5) Unix did have plenty of Y2K issues, because even though dates are stored internally as seconds since 1970, many utilities and libraries that translated dates to and from human readable form did have issues, along with many applications

Mustn't you feel a complete chump now?

An Essay highlighting the ignorance of others really ought to have some basis in fact - dont you think?

Try 1970.

Perhaps the comment author would like to practise what he preaches, before going off on a completely irrelevant and indeed factually wrong angle himself?

Ok, that's a nice little story about dates, but how does that have anything to do with malloc and memory allocation? Seems to me, that you are the one who didn't understand anything.

You are all ignorant people you know literally nothing about unix and the topic we are discussing. Next time, before posting or commenting, learn two basic things about the topic and come back then to comment.

The '1975 unix bug' has immediate relation to how the unix system registers the system dates. It's not that much of a 'bug' as a restriction that occurs from the specifications of unix.

In the unix system (and in many utilites and programs of unix) dates are stored a little differently as usual, which is as seconds elasped since 1st January 1975. For example, for unix, the system date "2nd January 1975", is stored as "86400", which means 86400 seconds after 1st Jan 1975, aka one day after, aka 2nd Jan 1975. This number is stored as a 32bit length number (in 32 bit systems). 

This helped unix (and many of it's utilities) to have no problem with the infamous "Y2K bug". For unix, the date 1st Jan 2000 is just a number like all else, the number "768960000" to be precise, aka 25 years after 1st Jan 1975, aka 1st Jan 2000. So, no problems with the Y2K bug.

However, numbers with 32 bit length can hold up to a certain number of digits. As years go by, the number that describes seconds elapsed since 1st Jan 1975 groes bigger, and more and more digits must be used to describe it. After many years, the number groes so big, that it can't fit in the digits provided by a 32bit length, and resets to zero. This date is calculated to be some date in the 2030s, (can't remeber exactly). 
In addition, since this number can't be negative, it can't hold system dates before 1st Jan 1975.

So, it's not unix's fault. First of all, it's the programmer's fault, who didin't used 64bit lenght number (can't hold many times more digits) for the number, as he should in a 64 bit system (32 bit lengths are used in 32 bit systems), and the maker of the compiler fault, who registered a system date before 1975, knowing (?) the restriction (not bug) of the unix for system dates.

Creative take note, you 2 could wait forever to fix your sound cards.

If it only manifests on Sparc64, has the bug really been around since 1975? 

One for the philosophers to ponder, methinks.

While YACC may have been used to build parts of Unix it wasnt part of the OS. 
It may still be used to create parts of Windows however, which would explain a lot, and of course allow you to headline with '1975 Windows flaw fixed' too.
Keep up the light skimming of reality.