In late 1997, researchers found that Intel’s Pentium and Pentium MMX processors could be frozen solid by a short, deliberately malformed instruction. The sequence began with the hexadecimal bytes F0 0F C7 C8, which gave the defect its memorable name: the F00F bug. Any program, even an unprivileged one, that executed this sequence would hang the entire machine, requiring a hard reset. On a multi-user or networked system, that made it a denial-of-service flaw, since one user’s process could take down the whole computer.
The root cause lay in how the Pentium handled an illegal instruction combined with a bus-locking prefix. The bytes encode a LOCK prefix (F0) applied to a CMPXCHG8B instruction (0F C7) whose operand field specifies a register instead of the required memory location. CMPXCHG8B with a register operand is already an invalid encoding and is supposed to raise an invalid-opcode exception. But with the LOCK prefix attached, the processor began a locked bus sequence to read the exception handler’s descriptor and then could not cleanly recover, leaving the bus locked and the CPU wedged.
Intel documented the defect in its specification update as the invalid-instruction erratum, classifying it as a design error in the affected processors. Intel’s own erratum overview confirms the failure mode: executing the invalid operand form of the instruction with a LOCK prefix can cause the processor to hang. The fix in silicon arrived in later steppings, which changed the decode and bus-locking logic so that an invalid operand no longer asserted the lock on the way to the exception.
Because installed machines could not be swapped overnight, the practical defense was a software workaround at the operating-system level. The trick was to rearrange the interrupt descriptor table so that the invalid-opcode handler sat on a page deliberately marked not-present. When the F00F sequence triggered the bus lock, the resulting page fault would fire first and could be caught by the kernel, which then redirected control to the real invalid-opcode handler. The faulting program was killed, but the machine kept running. Major operating systems, including Linux and Windows, shipped this kind of mitigation.
The F00F bug is a textbook example of a hardware erratum that ships in silicon and is contained in software. Like the earlier FDIV flaw, it could not be patched out of the chips already in customers’ hands, so the burden of working around it fell to system programmers. It also underscored a security lesson that would recur for decades: a low-level processor quirk, even one that looks like an obscure corner case, can become a real attack surface once anyone realizes an ordinary user program can trigger it.