Due to the proliferation of Intel microprocessors, the existence of this open-privilege instruction was considered a serious issue at the time.
Operating system vendors responded by implementing workarounds that detected the condition and prevented the crash.
No permanent hardware damage results from executing the F00F instruction on a vulnerable system; it simply locks up until rebooted.
Although a definite solution to this problem required some sort of hardware/firmware revision, there were proposed workarounds at the time[1] which prevented the exploitation of this issue in generating a denial-of-service attack on the affected machine.
These extraneous memory accesses turned out to be sufficient for the bus interface to let go of the locking requirement that was the root cause for the bug.
This descriptor, residing on the second page of the table, is present in memory as usual (if it were not, the processor would double- and then triple-fault, leading to a shutdown).
The handler for the page-fault exception has to be modified, however, to cope with the necessity of providing the missing page for the first half of the interrupt descriptor table, a task it is not usually required to perform.
Since the originating illegal instruction was supposed to issue a memory write cycle, this is enough for again forcing the intervention of the page-fault handler.