VERDICT — DF-4129 (sys/dev/sound/midi/sequencer.c seq_sync stack OOB) ======================================================================= STATUS: reproduced (vulnerable kernel, wired sequencer) / fixed (fix.diff validated in the same run). Impact: kernel stack control-flow corruption demonstrated as a reliable local kernel panic from an unprivileged process; uid=0 not reached (write content is the constant 1 — see ceiling below). 1. Root cause (source certainty) seq_sync() (sequencer.c:2060-2142) sizes its per-unit scratch array at 16 (`int i, rl, sync[16], done;`, :2063) but iterates `i < scp->midi_number` (:2123, :2128) — a count that seq_open (:766-785) derives from the number of registered snd_midi units, bounded only by the 32-entry midis[] kmalloc (:541-543). Every attached MIDI unit beyond the 16th therefore writes `1` past sync[16] on the calling thread's kernel stack (:2124) and reads it back (:2129). Both SNDCTL_SEQ_SYNC (via seq_ioctl :1202-1210) and close() (via seq_close :836-837) call seq_sync with seq_lock released at the write point (:2122) — no lock ordering involvement. Not a re-report of DF-1394 (that is the midis[] HEAP write at :773, needs >32 units) or DF-1393 (seq_fetch_mid off-by-one at :724): this is the sync[] STACK write in the 17..32 window. 2. Reachability — the pass-2 discovery that gates everything seq_addunit() has no live caller: the only seq_modevent() call sits inside `#if 0` (midi.c:1509, :1517) and sequencer.c registers no module. Live proof on the stock guest: `kldload sound` yields only /dev/midistat — no /dev/sequencer, /dev/music (baseline_stock.log). => on stock DragonFly the entire sequencer surface (this bug, DF-1393, DF-1394) is dead code today. The PoC re-enables the wiring with a 2-line patch (wiring_enable.diff — the FreeBSD wiring) and leaves sequencer.c untouched, demonstrating that the vulnerability is one `#if` away from live. If that wiring is ever restored, 17+ MIDI units (multi-port USB/PCIe MIDI interfaces enumerate one snd_midi per port; 8x8-port boxes reach 64) satisfy the precondition. 3. Reproduction narrative (guest: DragonFly 6.5-DEVELOPMENT #0, X86_64_GENERIC) a) baseline: stock sound.ko loaded -> no sequencer nodes. (Also observed: `kldunload sound` panics in sndstat_sysuninit() — PRE-EXISTING sndstat.c bug already on file from DF-4115's pack; not mine.) b) wiring_enable.diff applied to /usr/src midi.c; make nativekernel; /usr/obj/.../sound.ko installed -> kldload sound creates /dev/sequencer0 and /dev/music0, mode 0666 (wired_load.log). c) fakempu.ko built inside the kernel module obj tree (mpu_if KOBJ class, 8 methods; 32 units via exported midi_init(); midi.c's midimapper_open() then reports 32). Loaded: "fakempu: 32/32 fake MIDI units registered", 32 /dev/midiU.C nodes (fakempu_load.log; `ls /dev/midi* | wc -l` = 33 incl. midistat). d) TRIGGER as unprivileged user maxx (`/tmp/seq_sync_oob 3`): serial console shows the synth_if default stubs "noinsync" x N (the OOB read loop at :2129 executing for i>=16), then Fatal user address access from kernel mode from seq_sync_oob at 0000000000000000 Fatal trap 12: page fault while in kernel mode instruction pointer = 0x8:0x0 frame pointer = 0x10:0x0 current process = 42761 (the unprivileged trigger) (panic.txt). Guest dead at db> prompt. The smashed stack took RIP and RBP to ~0 — kernel control flow hijacked from an unprivileged process; the 0x00000001-word pattern of the `sync[i]=1` writes is the corruption source. 4. Fix validation (same run, same harness) fix.diff: introduce MIDIDEV_MAX=32; use it for the midis/midi_flags allocations (:544-546), size sync[MIDIDEV_MAX] (:2068), and clamp the seq_open enumeration (`i < scp->maxunits && scp->midi_number < MIDIDEV_MAX`, :776 — also closing the DF-1394 >32 heap window). Applied together with the wiring, kernel rebuilt, sound.ko reinstalled: the identical unprivileged trigger now completes "[+] survived 3 open/sync/close cycle(s)" with rc=0 and the guest stays up (fix_run.log). First fixed-kernel attempt with 128-byte fake out-queues hung in midisynth_writeraw ("Always blocking") during seq_reset's 16-channel controller flush — a pure harness artifact (the fake UART has no IRQ-driven drain; real hardware drains), not kernel-path behavior of the fix; rerun with 1024-byte out-queues is clean. On the vulnerable kernel this path never even runs (panic fires inside the ioctl first). 5. Exploit ceiling — why panic, not uid0 Primitive: 4..64 bytes of constant 0x00000001 written past a stack array, count attacker-influenced (attached-unit count minus 16), content NOT attacker-controlled. Demonstrated effect: saved RBP/RIP overwritten with 1-pattern values => return to a fixed invalid address => fatal trap. For uid=0 one would need either attacker-chosen data in the smashed slots (this write cannot), or a register-only corruption that survives to a useful gadget (no attacker-controlled pivot available from a constant). No pairing leak was found in this dead-wired surface. Verdict: reliable local kernel DoS / memory corruption class, no demonstrated escalation. 6. Bottom line Real, source-certain, live-demonstrated kernel stack overflow (reproduced/panic on the wired sequencer, fixed by fix.diff in the same run), currently gated by the sequencer personality being dead code on DragonFly (midi.c:1509). File the fix; if the sequencer is ever wired back on, this becomes a live unprivileged kernel-smash. ## 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.