# DF-1023 — Kernel panic on unrecognized SD CSD version

**File:** `sys/bus/mmc/mmc.c:1108-1109`
**Severity:** Medium (CVSS 3.6 / DoS)
**Class:** CWE-754 (Improper Check for Exceptional Conditions)

## Summary

`mmc_decode_csd_sd()` calls `panic("unknown SD CSD version")` when the
2-bit `csd_structure` field (read directly from the card's CMD9 R2
response, bits 126–127) is anything other than 0 or 1. The value is
fully card-controlled. A maliciously crafted SD card (or any future
SDUC / SD Spec 7.0+ card that legitimately defines CSD v2) immediately
panics the kernel at enumeration, which happens at boot if a card is
inserted, on `mmcbr_*` bus scan, or on `mmc_resume`.

The sibling decoder `mmc_app_decode_scr()` at `mmc.c:1158` handles the
analogous case correctly with `kprintf + return`.

## Reproducibility

* **Bug confirmed:** Yes — direct `panic()` call cited at `mmc.c:1108`.
* **Live reproduction on audit guest:** NOT FEASIBLE — the QEMU/KVM
  guest has no SDHCI PCI device (`pciconf -l` shows only hostb/isab/
  atapci/virtio_pci). The `mmc.ko` module exists but does not attach.
  No userspace path can reach `mmc_decode_csd_sd()` without SD/MMC
  hardware, so this is a latent/realistic-hardware bug rather than a
  dead-code path.

## Fix

Replace the `panic()` with a `kprintf + return`, matching
`mmc_app_decode_scr()`. The full `git apply`-able diff is in
`fix.diff`. The fix has been compile-validated (see `VERDICT.md`).

## Reproduce

```sh
./build.sh && ./run.sh
```

The PoC is a documentation harness — there is no SD/MMC hardware on
the audit guest, so the program prints the analysed call path and
explanatory markers instead of triggering the panic. To trigger the
actual panic, present a malicious SD card reporting `csd_structure=2`
or `3` to a host with an SDHCI controller and observe the kernel panic
at card enumeration.