February 25, 2026
One bit to crash them all
The History of a Security Hole
Decades-old Intel quirk lets a normal app nuke OpenBSD—comments go nuclear
TLDR: A 32-bit OpenBSD bug let normal apps write to hardware ports and kill the system, thanks to a decades-old Intel design with inverted permission bits. Commenters split between blaming vintage x86 baggage and roasting a “one sizeof away” oversight, calling it a reminder that old hardware ghosts still bite.
The nerd epic “History of a Security Hole” reads like tech archaeology, but the comments turned it into a popcorn-fueled drama. TL;DR: an old Intel design from the 80s collided with modern OpenBSD on 32-bit machines, letting a regular app flip a forbidden hardware switch and crash the whole OS. Cue gasps. The crowd’s hottest take? Blame the 80s: Intel stuffed an I/O permission map into a Task State Segment (a special memory block), and the bit meanings were upside-down—0 means allowed, 1 means blocked. One commenter explained that empty memory defaults to “all access allowed,” calling it “one sizeof away from correct.” Ouch. Another wry voice just wrote “(2018),” the minimalist meme for “how is this still happening.” The split: some roasted legacy Intel quirks for haunting modern systems, others jabbed at OpenBSD devs for letting zeroed memory hand out hardware keys like candy. The jokesters piled on with “A20 gate is the haunted attic of PCs,” and “This isn’t a bug, it’s archaeology.” Meanwhile, a few pragmatists warned this is why 32-bit builds are getting the cold shoulder. It’s a rare thread where history class meets crash course, and everyone brought receipts.
Key Points
- •A user process on 32-bit i386 OpenBSD 6.3 could crash the OS by accessing hardware I/O ports; amd64 was not affected.
- •The CPU crash state showed inaccessible kernel stack and GDT, leading to triple faults and shutdown.
- •The A20 gate was found disabled in protected mode, a condition with severe, unpredictable consequences.
- •Intel added the I/O permission bitmap to the 80386 TSS in late 1985 to enable per-task I/O control, especially for V86 mode.
- •The history of TSS and IOPB design changes, influenced by industry needs, contributed to conditions enabling the OpenBSD i386 vulnerability.