# VERDICT — DF-5123

**status: not_reproduced** (no miscompile manifests on the shipping compiler)
**reproduced: false · impact: none (latent) · confidence: likely**

## Narrative

The claim has two parts: (a) the inline asm in `hypercall_md()`
(`hyperv_machdep.c:74-84`) violates the GCC extended-asm contract —
**certain**, by inspection; (b) the violation can miscompile into a
hypercall with a corrupted r8 (output-page GFN) or reordered hypercall
page traffic — **latent**: not observed with the shipping compiler.

### What was run

`hypercall_md.c` (exact copy of the function + an `always_inline` variant)
was compiled on the audit guest (DragonFly 6.5-DEVELOPMENT, gcc 8.3
"cc 8.3 [DragonFly] Release/2019-02-22") at -O2 and disassembled
(`build.sh`, `objdump_gcc83_O2.txt`).

### What the disassembly proves

* In the standalone function, gcc emits the operand-setup move
  `mov %rsi,%rcx` **between** `mov %rcx,%r8` (asm #1) and `callq *-0x8(%rsp)`
  (asm #2). This is the structural precondition of the hazard: the gap
  between the two volatile asm statements is *not* a compiler-free zone,
  and the first asm telling the compiler "r8 is clobbered" means gcc
  considers r8 dead from that point — it may legally allocate r8 for the
  inter-asm moves of a different input set, silently destroying
  `out_paddr` before the call.
* In the `always_inline` variant (simulating what an LTO build could do to
  the real call site in `hyperv.c:108`), the same pattern appears inline
  in the caller; the missing "memory" clobber means any *non-volatile*
  loads/stores around the hypercall (i.e. the hypercall message-page
  writes done by `hypercall_post_message()`'s callers in vmbus.c) are
  freely reorderable across the asm — the demo's surrounding stores were
  volatile so no reorder was *expected* to show; that sub-claim remains
  inspection-based.

### What was NOT observed

With gcc 8.3 at -O2, r8 survives the gap in both shapes; no hypercall can
actually be issued on the guest anyway (it is a KVM guest —
`VMM/Hypervisor: Origin="KVMKVMKVM"` in `env.txt` — so `hyperv_identify()`
fails and the whole file is dormant, `hyperv.c:207-208`). Therefore the
exploitable consequence does not reproduce on this system: **status
not_reproduced / impact none**, while the underlying defect is certain.

### Why it still matters

The function is the *only* hypercall gateway on Hyper-V systems; a future
compiler upgrade, LTO, or an added statement between the asms turns the
latent contract violation into: hypercalls invoked with an attacker-
irrelevant but kernel-corrupting wrong output GFN, or message pages read
stale — failure modes that would be nearly undebuggable in production.
The one-statement fix (see `fix.diff`) removes the entire class.

## Fix validation

Not applicable (Info-class hardening; no runtime behavior to compare —
the code path is dormant on KVM and the miscompile does not manifest on
gcc 8.3).

## 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.