# DF-1023 — VERDICT

## Verdict

**NOT REPRODUCED (live) — bug CONFIRMED via code trace, fix.diff compiles cleanly.**

The kernel-panic bug claimed in the finding is real and the cited line
numbers are exact, but it cannot be exercised on the audit guest
because there is no SDHCI/MMC PCI host controller (the QEMU/KVM
guest's PCI bus exposes only hostb/isab/atapci/none/virtio-pci
devices) and therefore no code path that reaches
`mmc_decode_csd_sd()`. The bug is *latent* on this guest and *live*
on any host with an SD/MMC controller (real hardware, or QEMU started
with `-device sdhci-pci` + an sd-card image) into which a malicious SD
card is inserted.

## Mechanism (code trace)

`mmc_decode_csd_sd()` decodes the 128-bit CSD register that an SD card
returns in its CMD9 R2 response. The function:

* `sys/bus/mmc/mmc.c:1056`
  ```c
  csd->csd_structure = v = mmc_get_bits(raw_csd, 128, 126, 2);
  ```
  reads the 2-bit `csd_structure` field directly from card-controlled
  bytes (bits 126-127 of the CSD).

* `sys/bus/mmc/mmc.c:1057-1107` — `v==0` and `v==1` are decoded.

* `sys/bus/mmc/mmc.c:1108-1109`
  ```c
  } else
      panic("unknown SD CSD version");
  ```
  Any other value (e.g. `v==2`, the SDUC / SD Spec 7.0+ value; or a
  malicious `v==3`) immediately panics the kernel.

The call chain is `mmc_delayed_attach` → `mmc_discover_cards` →
`mmc_decode_csd_sd` (`mmc.c:1471` per the finding summary), which runs
at card-enumeration time — i.e. at boot if a card is present, on
hot-plug, or on `mmc_resume`. No user interaction is needed beyond
inserting the card.

The sibling decoder `mmc_app_decode_scr()` at `mmc.c:1158-1163`
handles the analogous case correctly:
```c
if (scr_struct != 0) {
    kprintf("Unrecognised SCR structure version %d\n", scr_struct);
    return;
}
```
The CSD decoder is missing the same defensive pattern.

## Why it does not reproduce on this guest

| Audit-guest fact | Evidence |
|---|---|
| No SDHCI/MMC PCI host controller present | `pciconf -l` lists only hostb/isab/atapci/none0/vgapci/virtio_pci0/virtio_pci1 — class 0x060500 / 0x0805 (SDHCI) absent |
| `mmc.ko` is shipped but never attaches | `kldstat` does not list `mmc.ko`; `ls /boot/kernel/mmc.ko` shows it is available but unloaded |

There is no code path on the audit guest that reaches
`mmc_decode_csd_sd()`. The bug requires physical access to an SD card
slot and a host with a real or emulated SDHCI controller.

## Exploit chain

`none` — pure DoS / improper-check (CWE-754). No memory corruption.

## Fix

`fix.diff` replaces the panic with `kprintf + return`, exactly
mirroring `mmc_app_decode_scr()`:

```c
} else {
    kprintf("unknown SD CSD version %d\n", v);
    return;
}
```

The `csd` struct is zero-filled at function entry (`memset` at line
1055) so a graceful return leaves the caller with an all-zero CSD,
which the existing capacity / timing code handles as "no card /
unknown".

## Fix validation

* `fix.diff` applies cleanly to `/usr/src/sys/bus/mmc/mmc.c` with
  `patch -p1` (1 hunk succeeded).
* The patched `mmc.ko` module compiles cleanly with `-Werror` (see
  `fix_build.log`).
* Not live-tested (no SDHCI HW to enumerate a card).

`fix_status: not_testable` (no live trigger available).

## PoC changes

The finding folder was empty; this run authored:
- `README.md` — full summary
- `poc.c` — documentation harness
- `fix.diff` — the verified fix
- `build.sh`, `run.sh`, `build.log`, `run.log`, `env.txt`,
  `fix_build.log`, `manifest.json`, `VERDICT.md`