# VERDICT — DF-4780

## Reproduced? YES — attach-time kernel panic, twice, deterministically

Trigger on the QEMU/KVM guest (stock kernel, family-0x0F CPU): `patchcpu.ko` substitutes
only the CPUID model advertisement (`cpu_id → 0x00030661`, family 06h model 36h
Cedarview — a model `corecstat_probe()` itself whitelists at corecstat.c:189), then
`kldload corecstat.ko` where corecstat.ko is the **stock, unmodified driver source**
with `#define INVARIANTS 1` on line 1 — i.e. exactly what any debug/INVARIANTS kernel
build (LINT64-style; LINT64 contains `device corecstat`) compiles. Verified before
loading that the module contains the KKASSERT panic string (grep -c assertion == 1).

Observed (full serial capture in panic.txt / run.log):

* cpu0..cpu4 (non-representative): `device_probe_and_attach: corecstatN attach
  returned 6` — the atom-v0 `else if` ENXIO path (corecstat.c:355-357).
* cpu5 (chip representative, BSR of the CHIP node's members): package sensors probed
  via `rdmsr_safe` (PC2/PC4/PC6 lines, graceful), then

  `panic: assertion "sc->sc_version != 0" failed in corecstat_init_atom_cpu at
  corecstat.c:425` (pristine-tree line 424; +1 from the prepended define)

  backtrace `corecstat_attach → device_doattach → bus_generic_driver_added →
  devclass_add_driver → module_register_init → Debugger("panic")`, all CPUs stopped,
  guest down in DDB, ssh hung (RUN_RC=124), `vm.sh status` ⇒ down.

## Why it fires (logic, not environment)

`corecstat_attach()`'s `else if (sc->sc_is_atom && sc->sc_version == 0) return (ENXIO)`
(corecstat.c:355-357) diverts only **non-representative** cpus. The chip representative
of an original Atom takes the first branch (CHIP nodes always have ≥1 child:
`child_no` is the child count, sys/kern/subr_cpu_topology.c:125) and then falls into
`corecstat_init_atom_cpu()` whose first statement is `KKASSERT(sc->sc_version != 0)`
(corecstat.c:424) — false by construction for exactly the five original-Atom models the
probe whitelist names (corecstat.c:186-191). Every original-Atom system hits this at
attach (boot-time panic if the driver is compiled in, kldload panic otherwise) **on
INVARIANTS builds**.

## Production builds (the honest gap)

`KKASSERT` is INVARIANTS-only (sys/sys/systm.h:94-119). On production kernels the
assert is compiled out and the "impossible" path executes: the representative
original-Atom cpu registers core C1 (MSR 0x660, Silvermont-only) and C6 sensor probes.
Both are `rdmsr_safe`-gated (corecstat.c:594-603), so this is wrong-behavior, not
memory corruption. Live-captured in run.log ("PRODUCTION-build fall-through":
`msr node0 core5 C1 res. (0x00000660) not available` from a version-0 softc).
Severity Low (panic class; DF-4735-comparable): the panic needs an INVARIANTS build,
which DragonFly ships as its standard debug configuration and which LINT64-style
configs make concrete (`device corecstat` + INVARIANTS). No unprivileged trigger:
attaching the driver requires boot or root kldload on original-Atom-class hardware
(or a VMM advertising those CPUIDs, as demonstrated).

## Exploit chain: none — panic/DoS class (no memory corruption)

## Fix validation: FIXED

`fix.diff` restores the author's documented design ("Only Package C-States available,
no Core C-states", corecstat.c:267) by guarding the atom dispatch on
`sc_version != 0`. Same trigger, fixed module (INVARIANTS define identical to the
baseline build): **no panic**, module loads (`FIXED_LOADED`), cpu5 probes **only** the
three package MSRs — the `core5 C1/C6` lines are gone — clean `kldunload`, guest stays
up (`vm.sh status` ⇒ up). A pleasing compiler certificate: with the fix, -O2
interprocedural analysis proves the assert condition always true (single static call
site now guarded) and dead-code-eliminates the panic path — the fixed .ko no longer
even contains the "assertion … failed in" string.

## Guest state

Returned clean: `vm.sh reset with-src` after all runs; no kernel or /usr/src
modifications persisted (trigger + fixed modules lived in /tmp only, on wiped disks).

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