DF-4094 — emu10k1 attach-failure path leaks emu_init DMA allocations + mpu401 state

File: sys/dev/sound/pci/emu10k1.c (pass 2, GLM 5.3)

What

emu_pci_attach() calls emu_init(sc) at sys/dev/sound/pci/emu10k1.c:2114. On success emu_init() has allocated and programmed:

• sc->mem.ptb_pages — EMUMAXPAGES*4 = 2048 bytes of bus_dmamem (emu10k1.c:1891-1892)
• sc->mem.silent_page — 4096 bytes of bus_dmamem (emu10k1.c:1896-1897)

After that, three more steps can still fail and jump to bad::

• AC97_CREATE() == NULL (emu10k1.c:2119-2120)
• mixer_init() == -1 (emu10k1.c:2122)
• IRQ alloc / snd_setup_intr() (emu10k1.c:2127-2133)
• additionally emu_midiattach() has already run (emu10k1.c:2124), so sc->mpu (kmalloc'd mpu401 + midi unit) is live too.

The bad: path (emu10k1.c:2149-2157) destroys codec/reg/irq/dmat/lock and frees sc, but never calls emu_uninit(), so the two DMA pages (~6 KB of coherent memory per failed attach) and the mpu401/midi structures leak. emu_init()'s own internal failure paths free their allocations correctly (emu10k1.c:1893-1901) — the leak is exclusively the late-failure window.

Threat model

Requires an emu10k1/emu10k2/emu10k3 PCI card whose attach fails late (e.g. shared-IRQ resource exhaustion, AC97 codec probe failure). Privileged/hardware-gated; impact is a kernel-memory leak per attach attempt (attach retries on bus rescans repeat the leak). No memory corruption, no info leak to userspace.

Source trace (certain, source-level)

1. emu10k1.c:2114 if (emu_init(sc) == -1) goto bad; — success continues
2. emu10k1.c:1891-1901 emu_init allocates ptb_pages + silent_page (kept on success)
3. emu10k1.c:2119-2133 any of AC97_CREATE / mixer_init / irq alloc fails → goto bad
4. emu10k1.c:2149-2157 bad: frees reg/irq/dmat/lock/sc — ptb_pages, silent_page, sc->mpu never released.

Fix

Track that emu_init succeeded and unwind via emu_uninit() in bad: (see fix.diff). emu_uninit() is safe to call in this window: it writes quiescent values to the card (already resources-mapped), frees both DMA pages, and only calls mpu401_uninit if sc->mpu != NULL (emu10k1.c:2038).

Reproduce

Hardware-gated: QEMU does not emulate emu10k1 (probe evidence in env.txt / run.log: no 1102:0002/0004/0008 PCI device, kldload snd_emu10k1 fails). Source-level certainty only.

DF-4094 VERDICT

Status: inconclusive on-guest (hardware-gated) / certain at source level. Impact: kernel heap/DMA leak (~6 KB + mpu401 struct per failed attach).

Was it reproduced?

No. The DragonFly QEMU guest has no Creative emu10k1 device — verified live: pciconf -l shows no vendor 0x1102 function, kldload snd_emu10k1 fails (run.log). The attach-failure path cannot be entered without the PCI device, so runtime reproduction is impossible on this guest. The defect itself is proven by source trace:

• emu_pci_attach() sys/dev/sound/pci/emu10k1.c:2114 — emu_init(sc) succeeds and allocates sc->mem.ptb_pages (emu10k1.c:1891) and sc->mem.silent_page (emu10k1.c:1896).
• Late failures at emu10k1.c:2119 (AC97_CREATE), :2122 (mixer_init), :2127-2133 (IRQ alloc/setup) all goto bad.
• bad: at emu10k1.c:2149-2157 releases reg/irq/dmat/lock and kfrees sc but never calls emu_uninit() (which is the only code that frees ptb_pages/silent_page — emu10k1.c:2035-2036 — and mpu401_uninit at :2038-2039, while emu_midiattach() ran at :2124).
• emu_init's own failure paths (emu10k1.c:1893-1901) free properly, so the leak is exactly the post-emu_init failure window.

Why not exploitable further

Pure allocation leak; no use-after-free (the leaked blocks are simply orphaned), no info leak, no attacker-controlled size. Trigger needs the physical card AND a late attach failure (resource exhaustion). Severity Low.

Fix validation

Not performed on-guest (would require emu10k1 hardware to build a kernel and fail an attach deliberately). fix.diff is a straightforward unwind fix:

int inited = 0;
...
if (emu_init(sc) == -1) goto bad;
inited = 1;
...
bad:
    if (inited)
        emu_uninit(sc);   /* frees ptb_pages, silent_page, mpu */

emu_uninit() is safe here: card registers are still mapped until the bus_release_resource that follows, EMU_INTE is zeroed first, and mpu401_uninit is guarded by if (sc->mpu).

kernel_refs

• sys/dev/sound/pci/emu10k1.c:2114 (emu_init success)
• sys/dev/sound/pci/emu10k1.c:1891-1901 (allocations + internal unwind)
• sys/dev/sound/pci/emu10k1.c:2119-2133 (late failure jumps)
• sys/dev/sound/pci/emu10k1.c:2149-2157 (bad: without emu_uninit)
• sys/dev/sound/pci/emu10k1.c:2035-2039 (what emu_uninit frees)

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.