Security1 distinct publisher2 min readPublished
A kernel exploit against HackSys' vulnerable driver pivoted onto a user-mode fake stack in Ring 0 and never faulted, because the syscall entry path sets the AC bit that suppresses SMAP.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
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.
Ranked by verification strength, evidence, and original report placement.
While developing a kernel exploit chain against the HackSys Extreme Vulnerable Driver (HEVD), Charfeddine abused an arbitrary write primitive to overwrite HalDispatchTable+0x8 and redirect execution through a stack pivot.
The pivot gadget was a 32-bit partial register move, mov esp, ebx ; ret, which zeroes the upper 32 bits of RSP and lands execution in a fake stack built in low user-mode memory via a VirtualAlloc below the 4GB boundary.
From the fake stack, a ROP chain disabled SMEP via mov cr4, rcx, jumped to a token-theft payload, and recovered the original kernel stack.
The exploit worked, returned SYSTEM, and the VM stayed stable long enough to pop a shell.
SMAP was enabled with CR4 bit 21 set, the fake stack was in user-mode memory, and the ROP chain executed in Ring 0 reading gadget addresses from a user-mode page.
The experiments were run on a Windows 11 VM, build 26200.8328.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-source experimental evidence
The post supplies concrete, reproducible artifacts: a WinDbg IA32_FMASK read, two minimal test drivers isolating whether AC survives vs. is set by the kernel, and a control test forcing AC=0 to rule out hypervisor suppression. It also cites converging prior art (hammertux, an MSRC 2020 paper). Evidence is internally strong but entirely self-reported from one author on one Windows 11 build in a VM, with no independent reproduction in the cluster.
No adoption signal
The cluster is a single research writeup describing lab experiments against a deliberately vulnerable training driver. There is no release, deployment, benchmark, usage disclosure, or real-world security incident to measure adoption from.
Slightly dramatic framing, largely calibrated
The title and 'pre-disarmed by design' framing are attention-grabbing, but the underlying claims are experimentally grounded and the author explicitly acknowledges prior art that already documented the behavior, so the framing only modestly overstates novelty relative to evidence.
Personal-brand research blog
The content sits on the author's personal research blog (with playful pixel-art styling and a 'Professional Mode' toggle), creating a reputational/portfolio incentive to present the finding as a striking discovery. There is no commercial product, sponsorship, or sale attached, keeping the incentive moderate.
Consistent single-source account
The assessment rests on one detailed, internally consistent, methodologically sound source that also cites corroborating prior art. Confidence is capped by the absence of any second publisher, independent reproduction, or vendor confirmation within the cluster, and by testing on a single Windows 11 build in a VM.
security
Windows 11's secure kernel trusts a RAM chip that never checks who is writing to it1 distinct publisher
build
Microsoft blames RGB software for KB5121003 crashes, so the fix is a driver hunt, not a rollback1 distinct publisher
build
wmic is gone, and Node's process trees on Windows 11 now come back empty1 distinct publisher
product
Beijing, not Redmond, now sets the retirement date for Windows 10's China build1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 23, 2026