DF-5769 — mmc_discover_cards() never terminates / unbounded child+ivar allocation for a card that keeps answering CMD2

File: sys/bus/mmc/mmc.c (pass 2, GLM 5.3) Class: CWE-400 (uncontrolled resource consumption) + CWE-835 (loop with unreachable exit condition)

What

mmc_discover_cards() (sys/bus/mmc/mmc.c:1413) enumerates cards in a while (1) loop whose only exits are CMD2 (ALL_SEND_CID) errors (mmc.c:1415-1422: err == MMC_ERR_TIMEOUT / err != MMC_ERR_NONE) and per-card error breaks. Per JEDEC, a real card leaves the identification state (stops answering CMD2) once it owns an RCA — termination is delegated entirely to the card. A crafted card that keeps answering CMD2:

• mutating CID — every pass looks like a new card (mmc.c:1426-1432 CID match loop never hits) → kmalloc(struct mmc_ivars) (mmc.c:1440-1441, ~0.7 kB, M_DEVBUF) plus device_add_child() (mmc.c:1704-1707, unnamed child, no unit ceiling) per iteration, forever: unbounded kernel-memory consumption, no path ever frees them (children are only attached at bus_generic_attach, mmc.c:1908, which is never reached);
• static CID — the same card is re-enumerated forever (ivar->rca = rca++ each pass, mmc.c:1572, wrapping uint16_t), discovery never returns.

Either way: the discovery context (config_intrhook / mmc_delayed_attach) is permanently wedged, the mmc bus is unusable, kldunload is impossible, and with mutating CIDs the kernel leaks memory without bound until the system degrades/dies. Reachable at boot or card-insertion/resume by any malicious MMC-mode card (SD probe is made to fail → mode_mmc, mmc.c:1779-1786).

How to reproduce (no SD hardware needed)

Same harness family as DF-5768 (production mmc.c compiled into the KLD, fake mmcbr bridge), built with DFH_MUTATING_CID: every CMD2 is answered with success and a fresh CID.

# guest (root), from a clean boot:
cd /tmp/df5769 && SYSDIR=/usr/src/sys make
sh ./run.sh          # kldloads in background, samples vmstat -m

Expected (stock kernel): mmc0 attaches, discovery loops forever in the dfh_boot thread; M_DEVBUF grows monotonically without bound (measured: 102 K → 89.1 M → 94.1 M over ~8 min, ≈110k allocations, still climbing; the O(N²) CID-match/device_get_children cost slows but never stops it); the guest eventually stops accepting ssh sessions; no crash — a pure wedge/exhaustion DoS. With the fix (fix.diff), discovery stops after 32 iterations, 32 mmcsd children attach, kldunload is clean and the guest stays healthy.

DF-5769 — VERDICT

Finding: mmc_discover_cards() has no host-side termination — a card that keeps answering CMD2 (ALL_SEND_CID) loops the enumerator forever and (fresh CIDs) allocates one mmc_ivars + one bus child per iteration without bound. File: sys/bus/mmc/mmc.c:1413-1710 (loop head 1413, exits only at 1417-1422; alloc 1440-1441; child add 1704-1707). Verdict: REPRODUCED — unbounded kernel-memory consumption / permanent wedge (DoS); fix validated on a patched kernel.

1. Root cause

mmc_discover_cards() enumerates while (1); the ONLY loop exits are CMD2 errors/timeouts (mmc.c:1417-1422) and per-card error breaks. Per JEDEC, a real card exits the identification state (stops answering CMD2) once it owns an RCA, so termination is delegated to the card. A crafted card that keeps answering CMD2:

• mutating CID — the CID-match loop (mmc.c:1426-1432) never hits, each pass is a "new card": kmalloc(sizeof(struct mmc_ivars)) (mmc.c:1440-1441, ~0.7 kB M_DEVBUF) + device_add_child (mmc.c:1704-1707, unnamed child — no unit ceiling, no devclass cap) per iteration, forever. The children are only attached (and only become freeable) at bus_generic_attach (mmc.c:1908) — which is never reached because discovery never returns.
• static CID — the same card is re-enumerated forever (ivar->rca = rca++ per pass, mmc.c:1572, uint16_t wrap) — non- terminating even without memory growth.

Consequences: the discovery context (config_intrhook / mmc_delayed_attach, mmc.c:1976-1982) is wedged forever; the mmc bus is permanently unusable; kldunload is impossible; kernel memory is consumed monotonically. Reachable at boot / card insertion / resume by any malicious MMC-mode card (the SD probe is made to fail → mode_mmc, mmc.c:1779-1786; the harness does exactly that).

2. Reproduction (no SD hardware)

Same harness family as DF-5768 (production mmc.c compiled into the KLD, fake mmcbr bridge) built with DFH_MUTATING_CID: every CMD2 answered with success and a fresh CID.

Baseline (stock kernel, clean snapshot):

DFH: MOD_LOAD (variant: DF-5769 mutating-CID)
DFH: boot thread: creating dfhbr0
mmc0: <MMC/SD bus> on dfhbr0          <- production discovery now loops forever

vmstat -m (M_DEVBUF "in-use"):
  fresh boot:                       102K
  t+~6 min:                        89.1M   (+ ~110,000 ivar+child allocations)
  t+~7.5 min:                      94.1M   (monotonic, unbounded)

• the monitored ssh session timed out (guest saturated); ~12 min after load the guest stopped accepting new ssh sessions entirely (serial console alive — pure wedge/exhaustion, no crash);
• kldunload impossible (the never-returning scan holds the module);
• there is NO exit condition in production code for this card behavior (verified by trace; the O(N²) CID-match/device_get_children cost at mmc.c:1424-1433 slows the loop over time but never stops it).

Honest scope note: on the 4 GB test guest the leak rate (after the O(N²) slowdown sets in) means full OOM takes hours; the demonstrated, code-certain property is unbounded growth + non-termination + permanent bus wedge from a single card insertion. impact=dos.

3. Fix validation

fix.diff bounds the loop host-side: while (iter++ < 32) at mmc.c:1415. Applied in the guest's /usr/src only (together with DF-5768's hunks — both in mmc.c, non-overlapping); rebuilt kernel #1: Sun Oct 11 18:02:40 UTC 2026; harness rebuilt against patched source; identical PoC re-run:

kldload rc=0
mmcsd0 .. mmcsd31 attach            <- exactly 32 cards, then discovery STOPS
mmcsd31: reading primary partition table: error accessing offset ... (fake
          card refuses reads -> normal production error path, no crash)
kldunload rc=0
vmstat -m: devbuf 227K              <- all card structures reclaimed

Guest healthy and responsive throughout; baseline wedge GONE.

4. Impact / threat

Malicious SD/MMC card at insertion/boot/resume → unbounded kernel memory consumption and a permanently wedged mmc subsystem (and, on the static- CID variant, an infinite non-allocating rediscovery loop that still blocks all card I/O). CWE-400 + CWE-835. DoS, not memory corruption.

5. Environment

See env.txt; guest restored to the clean with-src snapshot after the runs.

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.