# DF-5346 — VERDICT

**Status: not_reproduced** (by design of the harness): the fault requires a
hypervisor that advertises CPUID.7.EBX.SMAP under the VMM bit but faults the
CR4.SMAP write. QEMU/KVM implements CR4.SMAP, so the `+smap` boot passes
through the blacklist and boots cleanly — which itself documents the
finding's core claim: SMAP is NOT masked under VMM while SMEP/FSGSBASE are
(identcpu.c:674-676), contradicting the mask's own rule at :668-673
("extensions, activation of which requires setting a bit in CR4").

Evidence: boot-kvm-smap.log lines 35/38/40:
  Features2=0x80202001<SSE3,CX16,x2APIC,VMM>   (VMM present)
  Structured Extended Features=0x100000<SMAP>  (bit survived the blacklist)
  CPU Special Features Installed: SMAP         (cpu_implement_smap() ran)

Impact ceiling: boot-time #GP panic under a buggy/malicious hypervisor —
same class as DF-5345 and the same class the in-file rdmsr_safe guard at
identcpu.c:683-696 was added for. Speculative (no known shipping hypervisor
currently trips it); severity Low, hardening-consistency.

Fix validation: not_testable — cannot construct the faulting hypervisor
with stock QEMU 7.2 (CR4.SMAP is always accepted).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.