DF-1298 / DF-1305 / DF-1314 / DF-1315 — hardware-gated driver findings

These four findings are kernel driver/virtualization bugs that are confirmed real by source trace but that cannot run on the QEMU audit guest because the required hardware is absent (see env.txt):

Build

./build.sh

There is no userspace PoC binary to compile for these — the vulnerable code is inside a kernel driver/VMM module that only executes when the relevant device attaches or the SVM backend runs. build.sh documents this.

Run

./run.sh

run.sh performs a reachability check (kldstat, pciconf, dmesg) and reports that the path is unreachable on this guest. No panic/leak is expected here because the trigger hardware is absent.

Expected (bug present, on a host WITH the hardware)

Each VERDICT.md describes the exact trigger and the kernel-level effect (heap overflow / OOB write / host DR7 persistence). On this guest those are latent.

Reproduce the FIX validation

The fix for each is fix.diff. To compile-validate a module fix: 1. scp fix.diff to the guest; cd /usr/src && patch -p1 < fix.diff 2. Build the relevant module, e.g. cd /usr/src && make -j6 MODULES_OVERRIDE=... or a full make -j6 nativekernel KERNCONF=X86_64_GENERIC (which also builds modules). 3. Confirm the module/object compiles with no errors (see fix_build.log).

Runtime fix-behaviour cannot be compared on this guest because the PoC paths are hardware-gated; the fix is therefore classified not_testable with a compile + source-trace validation.

DF-1315 — AMD-SVM guest debug registers persist in host context (nvmm)

Verdict

NOT TESTABLE AT RUNTIME on this guest — confirmed real latent vulnerability in source.

Mechanism (confirmed by source trace)

sys/dev/virtual/nvmm/x86/nvmm_x86_svm.c is DragonFly's NVMM AMD-SVM backend.

AMD SVM does not save/restore host debug registers across VMRUN/#VMEXIT (there is no host-save-area field for DR0–DR7, unlike Intel VMX's VMCS host state). NVMM relies on software save/restore around the VMRUN:

• svm_vcpu_guest_dbregs_enter() (line 1486):
• calls x86_curthread_save_dbregs(cpudata->hstate.drs) — but the DragonFly version (nvmm_x86_internal.h:142) early-returns without saving when PCB_DBREGS is unset (the common case), so host DR7 is not captured;
• then x86_set_dr7(0) and loads guest DR0–DR3 into hardware.
• VMRUN runs the guest. With intercept_dr clear (no DR interception), the guest's MOV DR7 writes go straight to hardware DR7, and a guest can arm a data breakpoint on a host kernel address in DR0 + DR7.
• svm_vcpu_guest_dbregs_leave() (line 1500):
• saves guest DR0–DR3;
• calls x86_curthread_restore_dbregs(cpudata->hstate.drs) — which again early-returns without touching DR7 when PCB_DBREGS is unset. So the guest-armed DR7 stays loaded after #VMEXIT, and DR0 still holds the guest's chosen address.

Net effect: a guest under nvmm (AMD-SVM) can leave a hardware data breakpoint armed on a host address that persists into the host's execution context, so the next host code touching that address takes an unexpected #DB → host DoS (or worse, depending on host #DB handling). This is a host/guest isolation break.

Why it does not reproduce on this guest

• The guest CPU reports no AMD-SVM feature: AMD Features=0x20100800<SYSCALL,NX,LM> — the SVM bit (0x1000) is absent. NVMM's SVM backend will not initialise (no usable SVM), so the VMRUN path cannot be exercised, even if nvmm.ko were loaded (it is not in GENERIC and not loaded).
• nvmm is a pseudo-device listed only in LINT64, not in X86_64_GENERIC.

Severity / realistic ceiling

On an AMD host with SVM, with nvmm available and a VM run by a user able to open /dev/nvmm, a malicious guest can poison the host's debug registers and induce host-side #DB faults — a host DoS / isolation break (the finding's CVSS reflects AV:L/AC:L/PR:L/S:C/A:H). Requires SVM hardware + nvmm access (often root-only to load the module / create a VM).

Fix (see fix.diff)

• In svm_vcpu_guest_dbregs_enter: unconditionally save the host DR7 into cpudata->hstate.drs[DR7] before clearing it (so it is available to restore on exit regardless of PCB_DBREGS).
• In svm_vcpu_guest_dbregs_leave: unconditionally restore that host DR7 after the PCB-gated restore, so a guest-armed breakpoint cannot persist. This mirrors how the misc/FPU state is already handled. Compile-validated (nvmm module build); runtime not exercisable (no SVM on guest).