DF-4552 — snd_vibes attach-failure paths leave a live 0666 /dev/mixerN over released bus resources (DF-4156 family, 12th instance)

What this is

sv_attach() (sys/dev/sound/pci/vibes.c) publishes the mixer at line 789 (mixer_init(dev, &sv_mixer_class, sc)), which — see sys/dev/sound/pcm/mixer.c:730-733 — make_dev()s a mode 0666 /dev/mixerN cdev whose si_drv1->devinfo is the driver softc sc. Four later failure paths

• vibes.c:815-821 resource-assumption check (goto fail)
• vibes.c:837-840 dmaa allocation (goto fail)
• vibes.c:856-859 dmac allocation (goto fail)
• vibes.c:872-875 pcm_register failure (goto fail)

unwind with fail: (vibes.c:888-901): the DMA tag is destroyed, the interrupt is torn down and all bus resources (enh/dmaa/dmac) are released — but mixer_uninit() is never called (pcm_unregister(), the only caller of mixer_uninit — sound.c:1205 — is never reached on a failed attach, and even a hypothetical later pcm_unregister would return early because PCM_ALIVE(d) is false for a never-registered device). sc itself is also leaked (no kfree, including the early ENXIO return at vibes.c:746-749).

Result: after a post-mixer_init attach failure, /dev/mixerN stays world-RW with devinfo = sc whose cached bus_space_tag/handle pairs point at I/O port ranges rman no longer owns. Any local user (device is 0666 root:wheel) issuing mixer ioctls drives sv_mix_set() → sv_indirect_get/set() → bus_space_read/write_1 on released ports, which rman may have re-allocated to a different PCI device.

This is the 12th instance of the sound-family mixer-UAF/unwind-asymmetry family: DF-4156, DF-4193, DF-4299, DF-4334, DF-4344, DF-4421, DF-4457, DF-4468, DF-4504, DF-4537, DF-4550.

Reproduce (on hardware)

1. Machine with an S3 SonicVibes (PCI 5333:ca00).
2. Force sv_attach() to fail after mixer_init() — e.g. make the midi/games port-gap assumption fail (vibes.c:815-821) by having the PCI BIOS lay out the MIDI/GAMES BARs such that the gap is >= 0x800 or not 0x200-aligned, or patch a failure injection at vibes.c:874.
3. As an unprivileged user: cc -O -o mixer_probe mixer_probe.c && ./mixer_probe /dev/mixer0 — the MIXER_WRITE ioctl reaches sv_mix_set() over released ports.

What was run on the audit QEMU guest (2026-09-21)

The guest has no SonicVibes device (pciconf -l | grep 5333 → no match), so sv_attach never runs and the failure window cannot be entered. The probe was built on the guest and run anyway, as root and as an unprivileged user, to document the honest result:

/tmp/mixer_probe /dev/mixer0  →  open: No such file or directory   (no mixer0 published)
/tmp/mixer_probe /dev/mixer   →  open: Bad file descriptor         (default clone; zero pcm units registered → mixer_clone ENODEV path)

with snd_vibes.ko loaded (kldload snd_vibes), /dev/sndstat showing Installed devices: (empty). Logs: build.log, run.log.

Verdict

not_reproduced — the defect is certain at source level (same proven family pattern as 11 accepted instances), but this guest has no SonicVibes PCI hardware, so the trigger cannot be entered. See VERDICT.md.

DF-4552 VERDICT — not_reproduced on this guest (hardware absent); source-level: certain

Narrative

sv_attach() ordering (sys/dev/sound/pci/vibes.c):

mixer_uninit() (mixer.c:767) is only ever called from pcm_unregister() (sound.c:1205). A failed attach means device_is_attached() is false, so detach is never invoked, and even if it were, pcm_unregister returns 0 early because PCM_ALIVE(d) is false for the never-registered device — so nothing ever destroys the mixer cdev. Same asymmetry as the 11 accepted family instances (DF-4156 … DF-4550); in the other instances the fail path additionally kfrees the softc making it a heap UAF — here the softc leaks, so the live mixer drives bus_space_* on released I/O port resources instead (rman may have re-assigned them).

Post-failure reachability for an unprivileged user: /dev/mixerN is 0666 root:wheel (mixer.c:730-731). MIXER_WRITE → mixer_ioctl → sv_mix_set (vibes.c:541) → sv_gain → sv_channel_gain (vibes.c:483) → sv_indirect_get/set (vibes.c:139/151) using sc->enh_st/enh_sh, which were cached at vibes.c:750-751 from a resource released at vibes.c:896.

Also noted (folded into this finding): the early return ENXIO at vibes.c:746-749 leaks sc outright (no resource cleanup needed there, but no kfree), and every fail: path leaks sc.

Guest run (audit guest, 2026-09-21, uname in env.txt)

• pciconf -l | grep 5333 → no SonicVibes device present (QEMU/i440fx machine: only Intel PIIX + virtio + Red Hat VGA).
• kldload snd_vibes succeeds (module loads, probe finds nothing): /dev/sndstat → Installed devices: (empty); no /dev/mixer0 is ever created (mixer_init never runs).
• ./mixer_probe /dev/mixer0 (root and unprivileged): open: No such file or directory.
• ./mixer_probe /dev/mixer (the sound-core default clone node, sound.c:1426): open: Bad file descriptor — with zero registered pcm devices mixer_clone() (mixer.c:1340-1360) finds no PCM_REGISTERED unit and returns ENODEV; harmless here.
• Module unloaded again; guest left clean.

Incidental: the second unload cycle (without any cat /dev/sndstat in between) panicked the guest in sndstat_sysuninit() — that is the already-known DF-4116 (sndstat.c never-initialized sbuf deleted on sound.ko unload), reproduced live and consistent with its existing reproduced/panic verdict. Not a vibes.c defect; not re-filed here.

Bottom line

• Source-level defect: certain — identical, already-accepted family pattern; all four post-mixer_init failure paths enumerated.
• On this guest: not_reproduced — the PCI device does not exist, so the trigger window cannot be entered at all.
• Realistic impact ceiling on real hardware: unprivileged mixer ioctls poking I/O ports the driver no longer owns (worst case: another PCI device's registers), plus a permanent softc/mixer leak per failed attach. No kernel heap memory corruption (softc is leaked, not freed).

Fix validation

Not testable on this guest (no hardware). fix.diff is source-reviewed only: mirror the family fix — unwind the mixer before releasing resources on every failure path taken after mixer_init(), and free sc.

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.