This is the security mitigation in play, where if SMEP is enabled (and it is implemented and enabled by default on Windows 8+ systems as mentioned above) it will stop attackers from being able to execute exploits which rely on usermode shellcode (commonly within privilege escalation kernel attacks, attacker will prepare and have usermode based shellcode executed from a rin0 privileged point of view, giving them SYSTEM access, this is where attackers have kernel drivers, or the kernel system redirect execution to a user mode prepared shellcode)
And if the 20th bit is set to 0, SMEP is disabled and the access rights will depend on the paging mode and the value of IA32_EFER.NXE. For 32-bit paging, if IA32_EFER.NXE = 0, instructions may be fetched from any user-mode address. (SMEP disabled.
“CR4.SMEP, SMEP-Enable Bit (bit 20 of CR4) — Enables supervisor-mode execution prevention (SMEP) when set. See Section 4.6, “Access Rights”.”
The determination of access rights is split into either supervisor-mode access, or user-mode access, if the Current Privilege Level (CPL) is under 3 means it includes supervisor-mode access. And accesses that are CPL = 3 are user-mode accesses. The access rights depend on the value of SMEP (CR4.SMEP) as seen above.
How exactly are we affected? Well, with the addition of SMEP now on our system, we need to add a new section to our HEVD kernel exploit, we need to create our ROP chain which will flip that CR4.SMEP bit. If we can acomplish that, we can get our normal exploitation going.