content: The processor is doing the right thing. Changing the stack requires two instructions (change stack segment and change stack pointer). It needs to ensure that either both are changed or neither is changed. Having a half-changed stack leaves the program in an uninterpretable state. It does this by blocking all interruptions for one instruction after the stack segment is changed. The intention is that the next instruction will change the stack pointer, and the two instructions will execute as a pair with no interruptions. Any interruptions that occur will be deferred until after the second instruction. But the second instruction can be anything, not just changing the stack pointer. In this attack, the second instruction jumps to the kernel and runs at a higher privilege level. And then a deferred debugging interrupt occurs, meaning that the debugging jump is controlled by the unprivileged code but executed with kernel privileges. The documentation flaw is that the manuals did not clearly point out that this could happen and was hazardous.