SMAP was enabled. Windows had already set AC=1 and disarmed it.

The behaviour is not exotic once you read the enable condition closely. SMAP only enforces while RFLAGS.AC is clear; set the AC bit and the processor stops faulting on supervisor-mode reads of user pages. ^[7] So the real question was never whether the exploit was clever, but whether AC was somehow clear in the kernel and got set, or arrived set and stayed that way.

Charfeddine's first guess was that the syscall entry masking clears AC, which would keep SMAP live inside the driver. It does not. The IA32_FMASK MSR that SYSCALL uses to scrub flags read back as 0x4700, which clears the trap, interrupt, direction and nested-task flags and leaves bit 18 untouched. ^[8] A test driver then confirmed the flag is present rather than absent: when the client raised AC before the call, the handler saw AC=1 at its first instruction. ^[9]

The rest of the chain is unremarkable, which is the point. Once pivoted, the ROP disabled SMEP through mov cr4, rcx, ran a token-theft payload, and restored the kernel stack. ^[3] It returned SYSTEM, and the VM stayed up long enough to pop a shell. ^[4] Nothing in that sequence should have survived a supervisor read of a low user-mode allocation with SMAP on, and all of it did.

One thing the published excerpt leaves open is virtualization. The work ran in a VM, so Charfeddine set up a further check that forces AC back to zero inside the driver and repeats the read, to rule out QEMU/KVM quietly eating the fault. ^[12] That result is not in the material here, so for now the finding is scoped to Windows 11 build 26200.8328 under a hypervisor. ^[6] The narrow lesson holds regardless of how that test lands: the presence of a mitigation bit and the blocking of a primitive are two different measurements, and this chain measured both.