DF-5106 — emu_midi_detach() ignores mpu401_uninit() failure (emu10kx-midi.c)

Finding: sys/dev/sound/pci/emu10kx-midi.c:229 — emu_midi_detach() discards the return value of mpu401_uninit(). When any process holds the MIDI cdev open (/dev/midiN.M, created 0666 by midi_init()), mpu401_uninit() → midi_uninit() returns ENXIO without freeing the mpu401, the snd_midi, or destroying the cdev — yet emu_midi_detach() still returns 0. newbus then kfrees the device softc (kern/subr_bus.c:2148 → device_set_driver(dev, NULL) → kfree(dev->softc, M_BUS)) while:

• the cdev stays live with si_drv1 = m (any user can keep using it),
• m->cookie and the armed m->timer callout reference the freed softc,
• m->si points into the now-unloadable driver module.

What is in this pack

Build (on the DragonFly guest, root)

mkdir -p /usr/src/sys/dev/sound/driver/simid
cp simid.c /usr/src/sys/dev/sound/driver/simid/
cat > /usr/src/sys/dev/sound/driver/simid/Makefile <<'EOF'
.PATH: ${.CURDIR}/../../midi
KMOD=   simid
SRCS=   device_if.h bus_if.h mpufoi_if.h
SRCS+=  simid.c
COPTS+= -DFIXED          # only for the fix-validation build

.include <bsd.kmod.mk>
EOF
cd /usr/src/sys/dev/sound/driver/simid && make obj && make
cp /usr/obj/usr/src/sys/dev/sound/driver/simid/simid.ko /tmp/poc/
cc -O -o /tmp/poc/trig /tmp/poc/trig.c

Run

Stage A (deterministic, non-fatal):

kldload /tmp/poc/simid.ko
# as unprivileged user:
/tmp/poc/trig 90 /dev/midi0.0 &
# as root:
sysctl hw.simid_detach=1     # the emu_midi_detach body: ENXIO printed + IGNORED
sysctl hw.simid_spray=1      # heap churn after the free
sysctl hw.simid_peek=1       # deliberate read of the freed softc slot

Stage B (full kldunload scenario → panic):

kldload /tmp/poc/simid.ko
# as unprivileged user:
/tmp/poc/trig 300 /dev/midi0.0 &
# as root:
kldunload simid              # returns 0 (!), kernel panics <=1 tick later

Expected (stage B): simid[kldunload]: mpu401_uninit() returned 6 ... IGNORES, softc kfree'd, then Fatal trap 12: page fault while in kernel mode, instruction pointer = 0xffffffff82600120 (unmapped module text), current process = Idle (softclock/callout context), db> prompt — guest dead.

Why a simulation module

QEMU does not emulate the EMU10Kx PCI audio device, so the real snd_emu10kx driver never attaches in a VM. The bug, however, lives in the hardware-independent teardown sequence (mpu401_uninit → midi_uninit → newbus softc free → leaked cdev/callout/m->si), all of which is framework code that runs identically for any mpu401 consumer. simid.c reproduces that sequence verbatim (same mpu401_init/mpu401_uninit calls, same ignored-return detach body, same module-unload behaviour), so the observed behaviour is the framework's true behaviour for this exact bug.

DF-5106 VERDICT — emu_midi_detach() ignores mpu401_uninit() failure

Status: REPRODUCED (framework level; hardware-gated on the real driver) Impact: kernel memory corruption (use-after-free) + deterministic kernel panic via kldunload; unprivileged-user-reachable consequence after a privileged detach trigger.

The bug (code trace)

sys/dev/sound/pci/emu10kx-midi.c:222-233:

static int
emu_midi_detach(device_t dev)
{
        struct emu_midi_softc *scp;

        scp = device_get_softc(dev);
        mpu401_uninit(scp->mpu);                 /* :229  rv DISCARDED */
        emu_intr_unregister(scp->card, scp->ihandle);
        lockuninit(&scp->lock);
        return (0);                              /* :232  success anyway */
}

mpu401_uninit() (sys/dev/sound/midi/mpu401.c:196-207) propagates midi_uninit()'s error and does not free the mpu401 when it fails. midi_uninit() (sys/dev/sound/midi/midi.c:394-422) fails with ENXIO when m->busy and no reader/writer is asleep — i.e. exactly when an unprivileged user simply holds /dev/midiN.M open (the cdev is created 0666 by midi_init(), midi.c:364-366; midi_open() sets m->busy, midi.c:653). On that failure path the mpu401, the snd_midi (still in the global midi_devs list) and the cdev all survive — but emu_midi_detach returns 0, so newbus tears the device down anyway: kern/subr_bus.c:2148 device_set_driver(dev, NULL) → kern/subr_bus.c:1943-1946 kfree(dev->softc, M_BUS).

Post-detach state (all verified live on the guest):

• /dev/midiN.M still exists, mode 0666, si_drv1 = m (midi_destroy never ran) — any user can keep reading/writing it;
• m->cookie = the freed struct emu_midi_softc — every mpufoi callback (emu_mread/emu_mwrite/emu_muninit) dereferences freed memory, and emu_mwrite writes MMIO through sc->card read out of the freed slab (emu10kx-midi.c:85-93 → emu_wrptr(sc->card, ...));
• the mpu401 callout (m->timer) stays armed with m->si = emu_midi_intr inside the unloadable module (mpu401.c:162-166, mpu401.c:265-267);
• on kldunload snd_emu10kx(_midi) the module text is unmapped while m, the cdev and the callout persist.

Reproduction (guest, 3 baseline runs + 1 fix run)

Hardware note: QEMU does not emulate EMU10Kx, so snd_emu10kx cannot attach; verification runs the exact teardown sequence of the driver against the real mpu401/midi framework via simid.c (same mpu401_init/mpu401_uninit calls and the same ignored-rv detach body). Guest source md5-identical to the audit tree (env.txt).

Stage A (run.log): with uid-1001 trig holding /dev/midi0.0 open and writing, sysctl hw.simid_detach=1 ran the detach body:

simid[sysctl]: mpu401_uninit() returned 6 (FAILURE - m NOT freed, midi cdev STILL LIVE)  <<< emu_midi_detach IGNORES this and returns 0
simid[sysctl]: softc kfree'd (newbus behaviour after detach()==0); mpu401/snd_midi/cdev/callout still alive
simid: UAF: softintr on FREED softc 0xfffff801175f2f58 magic=51d10505 mpu_intr=0xffffffff82627fd0

• mpu401_uninit() returned 6 (ENXIO) exactly as traced — the failure emu_midi_detach discards;
• the softc was freed while the framework objects stayed alive;
• the still-armed mpu401 callout then invoked m->si(m->cookie) on the freed softc (kernel read of freed 120-byte M_DEVBUF/M_BUS-class memory through the framework) — the unprivileged user's writes keep this arming indefinitely;
• /dev/midi0.0 still present, trig (uid 1001) still running — the leak.
• The 64-block spray did not land on this particular freed slot in this run (peek showed stale content) — content control of the freed slot is standard kmalloc-zone grooming, demonstrated here only as a stale read.

Stage B (run.2.log, panic.txt — reproduced twice, identical fault address both times): with trig writing, kldunload simid returned 0 (the "clean success" the admin sees) and the kernel panicked within one callout tick:

simid[kldunload]: mpu401_uninit() returned 6 (...)  <<< IGNORES this and returns 0
simid[kldunload]: softc kfree'd ...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffffffff82600120     <- unmapped module text
instruction pointer   = 0x8:0xffffffff82600120 <- RIP jumped via stale m->si
current process       = Idle                   <- softclock/callout context
db>

0xffffffff82600120 is inside the just-unloaded module's mapping — the callout's indirect call through m->si. On the real driver this is kldunload snd_emu10kx (or card removal) while any user holds the MIDI device open: silent "success" → guaranteed panic.

Fix validation (run.3.fixvalidation.log): rebuilding the module with the exact semantics of fix.diff (abort the detach when mpu401_uninit() fails, i.e. MOD_UNLOAD returns the error):

simid[kldunload]: mpu401_uninit() returned 6 (...)  <<< IGNORES this and returns 0
simid[kldunload,FIXED]: aborting detach (device stays attached, softc NOT freed, module NOT unloadable)
kldunload: can't unload file: Device not configured      (RC=1)
GUEST_STILL_ALIVE

No free, no UAF, no panic; the admin now correctly sees the unload refused. (Baseline for the same run pair: identical unfixed build panicked at the same VA — the accidental second unfixed run doubles as a stress re-run.)

Exploit chain assessment (uid0?)

Primitive on real hardware, after the admin action (kldunload / card unplug) while the attacker's fd is open:

1. freed ~120-byte device softc (M_BUS zone) whose contents the attacker re-grooms via same-size allocations;
2. unprivileged fd I/O drives emu_mread/emu_mwrite(cookie=freed): emu_wrptr(sc->card,...) computes sc->card from the freed slot → attacker-chosen bus-space tag/handle → arbitrary kernel-scope write;
3. emu_midi_card_intr (or the callout) calls (sc->mpu_intr)(sc->mpu) — both read from the freed slot → arbitrary kernel call with one argument;
4. alternatively the unmapped-module m->si jump after unload is a reusable-VA call primitive.

That is a plausible unpriv→root chain on a machine with a SoundBlaster Live!/Audigy. It is not completable on this guest: the entire attack surface requires the emu10kx PCI device to be present (probe never binds without it; no cdev is ever created). This is a hard environmental blocker, documented rather than hand-waved: every step up to (but excluding) the final MMIO/call primitive was reproduced live.

Root cause line

• sys/dev/sound/pci/emu10kx-midi.c:229 — mpu401_uninit() return value discarded; :232 unconditional return (0).
• enabling conditions: sys/dev/sound/midi/mpu401.c:196-207, sys/dev/sound/midi/midi.c:394-422 (ENXIO on busy), midi.c:364-366 (0666 cdev), sys/kern/subr_bus.c:2148,1943-1946 (softc kfree).

Recommended fix

Propagate the failure (fix.diff): rv = mpu401_uninit(scp->mpu); if (rv != 0) return (rv); — validated on the guest (run.3): unload then fails cleanly, nothing is freed, nothing dangles, no panic.

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.