SMAP is Pre-Disarmed: How a Stack Pivot That Shouldn't Work Revealed a Kernel-Wide Design Compromise
Source Reddit NetSec
Discussion
This research highlights a design compromise in the Windows kernel related to Supervisor Mode Access Prevention (SMAP). Specifically, it experimentally confirms that SMAP is effectively disabled during standard IOCTL dispatches, allowing a stack pivot into user-mode memory without triggering SMAP protections. This behavior stems from the Windows kernel not being originally built with SMAP in mind, and retrofitting it would require extensive changes. The finding is a confirmation of an architectural limitation rather than a newly discovered vulnerability with an active exploit.
r/netsec (opens in a new tab)u/Important_Map69280 points0 comments
While working through a kernel exploit chain on Windows 11, I noticed that a stack pivot into user-mode memory didn't trigger SMAP.
I wrote up three experiments to figure out why. Short version: the normal syscall entry path arrives with RFLAGS.AC=1. SMAP is effectively disabled for any code reached through a standard IOCTL dispatch. This aligns with what MSRC documented back in 2020 (the Windows kernel simply wasn't built with SMAP in mind, and retrofitting it would touch ~2,900 locations: here)
My conclusion isn't novel here. It's just an experimental confirmation of the architectural compromise on current builds. I just wanted to shine the light on this blind spot.