Use after free in Windows Projected File System allows an authorized attacker to elevate privileges locally.

TOCTOU use-after-free (CWE-416) in the Windows Projected File System filter prjflt.sys, local EoP. PrjfRevertInMemoryTombstonesForDirectory (called from the IRP_MJ_CLEANUP post-callback PrjfPostCleanup) traverses the in-memory tombstone RTL_DYNAMIC_HASH_TABLE at context+240, guarded by an ERESOURCE at context+136. For each entry it selects the entry under the lock, then FltReleaseResource and KeWaitForSingleObject with NO timeout (indefinite). PRE: only after the wait does it read the tombstone attribute byte directly from the shared entry (*(char*)(entry+0x18), LOBYTE(v14[1].Linkage.Flink)) and pass it as arg3 to PrjfCreateTombstone. In the release->wait window another thread can take the ERESOURCE and modify the entry, so PrjfCreateTombstone gets a corrupted/attacker-influenced attribute flag -> wrong tombstone type / ProjFS state corruption; the no-timeout wait widens the window to seconds. IN-HOUSE ghidriff of prjflt.sys 10.0.26100.8328 -> .8457 (May 12 2026, KB5089549) confirms the fix: gated behind CFR flag Feature_1526925624, the function captures the attribute byte into stack local local_e7 while holding the lock (capture-before-release) and uses that snapshot after the wait instead of re-reading the shared entry. Note: our x64 24H2 diff shows Feature_1526925624, differing from the circulated screenshots' Feature_1795361080 (build/arch difference); the capture-before-release mechanism is identical. We ship what our diff shows.

The cleanup callback reads a tombstone attribute after releasing the lock, so a racing thread can swap the value used to create the tombstone

Derived from the patch delta: the checks added by the vendor identify which fields crossed a trust boundary unvalidated. Reachability and privilege are taken from the call chain in the RCA report.

ChenJian with Sea Security Orca Team