# DF-5160 — VERDICT

**Status: reproduced (driver-level). Impact: panic (privileged/boot-time DoS,
no privilege boundary crossed). Severity: Low. Confidence: likely.**

## Root cause

`sys/dev/misc/aperf/aperf.c`:

- `aperf_sensor_task()` executes `aperf = rdmsr(MSR_APERF); mperf =
  rdmsr(MSR_MPERF);` (**aperf.c:159-160**) with the raw inline-asm `rdmsr`
  (`sys/cpu/x86_64/include/cpufunc.h:528-535`) that has no #GP handling — a
  faulting MSR in kernel mode is a fatal trap.
- The task is registered with period 1s per CPU (`aperf.c:131`), and the
  FIRST invocation already performs the raw reads (`aperf.c:157-161`), so the
  panic fires ~1s after attach — at boot for a compiled-in driver.
- The only gate is `do_cpuid(0x00000006, regs); if ((regs[2] & 1) == 0)
  return;` in `aperf_identify()` (**aperf.c:88-90**). This is the
  DF-4735/DF-5155 lying-CPUID class: CPUID is not the MSR. The in-tree
  sibling `perfbias` at least guards `cpu_high < 6 || cpu_vendor_id !=
  CPU_VENDOR_INTEL` before `do_cpuid(6)` (perfbias.c:99); aperf has no
  `cpu_high` check at all, so on CPUs whose max basic leaf < 6 the documented
  Intel "echo the highest implemented leaf" behavior can feed foreign ECX
  data into the bit test (secondary, platform-dependent).
- The driver already imports the sensors framework and could use
  `rdmsr_safe()` (declared `cpufunc.h:1004`) exactly as coretemp does for
  `IA32_TEMPERATURE_TARGET`.

Reachability: `aperf` is not in `X86_64_GENERIC` (LINT64:1670 only) — a
kernel with `device aperf` on a lying platform panics ~1s after boot with
zero user interaction; otherwise root can `kldload` it. No unprivileged
trigger exists.

## How it was reproduced (three runs, one guest)

Guest: DragonFly 6.5-DEVELOPMENT #0 (Jul 2 2026) X86_64_GENERIC,
KVM, 6 vCPUs (env.txt: qemu64 "Intel" family 0xf model 0x6b;
env.2.txt: `-cpu host` = Xeon E3-1275 v5 / Skylake).

1. **Stock-driver gate observation (both CPU models).** Stock `aperf.ko`
   built -Werror from the unmodified guest source loads but never attaches:
   KVM presents CPUID.06H ECX=0 on qemu64 *and* on `-cpu host`
   (approbe/run.2.log: `max basic leaf = 0x00000016`, `06H EAX=4 ECX=0`),
   while `rdmsr_safe(0xE7/0xE8)` returns **14 (EFAULT)** on both. That is,
   the bare Skylake has the APERF/MPERF CPUID bit; KVM strips it precisely
   because it does not virtualize the MSR — the exact policy DF-5155 proved
   for leaf-6 MSRs. The CPUID gate is therefore the only protection, and it
   is the thing that lies on the vulnerable-platform class.
2. **Trigger-level (run.log/panic.txt, qemu64).** `aptest.ko` prints the
   gate state, shows `rdmsr_safe` = 14 twice, then executes the verbatim
   `aperf.c:157-161` body: `Fatal trap 9: general protection fault while in
   kernel mode ... current thread = pri 6 (CRIT) ... Stopped at
   aptest_modevent+0xd2: rdmsr` → DDB, guest down. The CRIT priority matches
   the sensor task's `crit_enter()` context.
3. **Driver-level (run.2.log/panic2.txt, -cpu host).** `lie.ko`
   (DF-4735-documented technique) force-adds `aperf` children to the cpu
   devices — substituting ONLY the missing CPUID advertisement. The stock,
   unmodified driver attaches (`aperf0..aperf5: <CPU Frequency Sensor> on
   cpuN`) and its real task traps: **`Stopped at aperf_sensor_task+0x48:
   rdmsr`** → DDB, guest down. (Six per-CPU tasks fault within the same
   second; the concurrent DDB entry garbled the trap banner itself, but the
   stock function name in the stop line is decisive.)

## Fix validation (run.3.log)

`fix.diff` (git-apply-able, `git apply --check` clean; also `patch(1)`-applied
inside the guest against `/usr/src/sys/dev/misc/aperf/aperf.c` whose md5
`efc02589720a8f59311a7d396ed325b2` matches the audit tree):

1. adds `#include <machine/md_var.h>` and an `cpu_high < 6` guard before
   `do_cpuid(6)` in identify (echo-hardening, mirrors perfbias.c:99), and
2. replaces the raw pair with `rdmsr_safe()`, skipping the sample on fault.

The patched driver built clean under `-Werror`, was loaded and force-attached
via the same `lie.ko` on the same faulting platform: all six CPUs attached,
tasks fired every second for the whole run, **no trap**, guest alive,
`hw.sensors.cpuN.freq0: unknown (cpuN freq), UNKNOWN` — the intended degraded
behavior when the MSR faults. `apfix.ko` (patched body, verbatim shape)
prints `rdmsr_safe(MSR_APERF)=14 -> sample skipped, NO TRAP`. Baseline vs
patched on the identical setup: trap-in-stock-driver vs alive-with-patched-
driver.

## Negative results (classes hunted and killed)

- **div-by-zero (mperf==0):** explicitly guarded at aperf.c:183-184; the
  diffs are unsigned wraparound-safe (aperf.c:171-172).
- **detach UAF / task lifetime:** `sensor_task_unregister2()` takes the
  per-CPU `thr->lock` and clears `running` under it (kern_sensors.c:264-266);
  the task thread runs `st->func()` under the same lock (kern_sensors.c:307,
  334) and only re-enters a task after the `running` check at
  kern_sensors.c:328-331 — no window where `aperf_sensor_task` touches `sc`
  after `aperf_detach` returns (aperf.c:141-145 stops the task before
  detaching the sensor). No UAF.
- **attach error path:** `CPU_GET_SENSDEV` NULL-checked (aperf.c:118-120);
  `sensor_task_register2` allocates with M_WAITOK (kern_sensors.c:280) so it
  cannot return a dangling/failed pointer worth a check.
- **sysctl read races:** `sensor_set` writes aligned 64-bit value/status;
  torn reads are not a memory-safety issue on x86_64 and the sensor value is
  world-readable by design (envstat).
- **integer overflow:** `aperf_diff * (tsc_diff/1000)` (aperf.c:187) can at
  worst mis-report frequency; no memory effect.
- **SMP per-CPU pinning:** task is registered per-CPU via
  `sensor_task_register2(..., cpu)` (aperf.c:131) and runs on that CPU's
  sensor thread; MSRs are read on the owning CPU. Correct.

## Bottom line

Real, driver-level-reproduced fatal trap in shipped source, same
lying-CPUID class the project has already accepted twice (DF-4735, DF-5155),
with strictly weaker reachability (LINT64-only device, root-gated load) —
Low severity, fix authored and build/boot-validated end-to-end on the guest.

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