Given how long 64-bit processors have been on the market, it's a bit surprising to see a vulnerability that takes advantage of AMD's x86-64 instruction set on Intel processors surface this late in the game. The vulnerability was originally thought to be Linux-specific, but was only recently found to be exploitable in Windows, BSD, and potentially OS X.

Originally Rafal Wojtczuk, the vulnerability takes advantage of the intricate mechanics of how memory is copied from one security level to another. In a nutshell, when AMD was creating its x86-64 instruction set, it opted to restrict the addressable memory space to 48-bits, leaving bits 48 through 64 unused. In order to prevent hackers from putting malicious data in this out-of-bounds area, AMD's processors require something called canonical addresses, where bits 48 through 64 have identical and meaningless data. If a ring three, or unprivileged user tries to elevate their privileges with non-canonical addresses in tow, AMD's processors will throw a general protection fault and then attempt to reload software from a safe place at the kernel level.

Intel's processors work very similarly, but have a subtle difference in how they handle these addresses. These processors check for canonical addresses at a different stage in the elevation process, allowing a clever hacker to introduce a specially crafted stack of code that tricks Intel's processors into restoring a non-canonical addresses after the general protection fault. Once this has happened, a kernel-level process has been pointed to an out-of-bounds area where malicious code could be waiting for execution at the highest security level.

This sounds disastrous, but Microsoft and many others have already released a patch for the vulnerability. Intel hasn't made an official statement about the flaw, which isn't a surprise considering that its processors are operating within the guidelines laid out in its published specifications. The vulnerability requires a specially crafted block of code to be executed by a local user, making the odds of it being used in the real world very low — especially after this week's round of patches. On the other hand, the expedience with which software companies responded to the problem shows how seriously they take kernel level vulnerabilities.