DF-4283 — midi(4) kqueue filter detach removes knote from BOTH klists → NULL-deref panic

What

midi_kqfilter() (sys/dev/sound/midi/midi.c:901-930) inserts each knote into exactly ONE of m->rkq.ki_note (EVFILT_READ) or m->wkq.ki_note (EVFILT_WRITE), but the shared detach callback midi_filter_detach() (midi.c:932-941) removes the knote from both lists. knote_remove() (sys/kern/kern_event.c:1902-1909) is a plain SLIST_REMOVE (sys/sys/queue.h:208-219) with no membership guard: for a knote that is not in the list it walks curelm = SLIST_NEXT(curelm, ...) until curelm becomes NULL and dereferences it — page fault on the unmapped low page → kernel panic. (Empty foreign list: immediate NULL deref; foreign list holding a different knote: walk to the end, then NULL deref — both modes demonstrated.)

Correct in-kernel idiom for comparison: sys/kern/tty.c:1308-1314 / 1334-1340 use one detach callback per list.

Trigger (unprivileged, when a MIDI device exists)

/dev/midiN.M is created with mode 0666 (midi.c:364-366). Any local user:

fd = open("/dev/midi0.1", O_RDWR);
kq = kqueue();
EV_SET(&kev, fd, EVFILT_READ, EV_ADD, ...); kevent(kq, &kev, 1, ...);
/* any of: EV_DELETE, close(kq), process exit  ->  filter detach -> panic */

Detach fires via knote_detach_and_drop() on EV_DELETE (sys/kern/kern_event.c:1365-1368) and on kqueue teardown (sys/kern/kern_event.c:706-708). It is enough to run kevent(2) once with EV_ADD and exit the process.

Hardware gating (why no live kernel trigger on the audit guest)

/dev/midiN.M exists only when some driver calls midi_init(). The only in-tree caller chain is snd_emu10kx → emu_midi_attach → mpu401_init() (sys/dev/sound/pci/emu10kx-midi.c:201 → sys/dev/sound/midi/mpu401.c:185 → midi_init). QEMU cannot emulate an EMU10K1/EMU10K2 PCI audio card, so the raw-MIDI node cannot appear on the audit guest. On real hardware with a SoundBlaster Live!/Audigy (driver auto-loads), the panic is deterministic.

Reproduce (model harness — runs on the guest)

cd findings/poc/DF-4283
./build.sh          # cc -O0 -g -Wall -o midi_kq_model midi_kq_model.c
                    # cc -O0 -g -Wall -o kq_trigger kq_trigger.c
./run.sh

Expected (see run.log): - empty → SIGSEGV at faulting address 0x0, exit 99 (kernel: panic) - peer → SIGSEGV at faulting address 0x0, exit 99 (kernel: panic) - fixed → clean removal, exit 0 (fix.diff semantics) - control→ clean, exit 0 - kq_trigger /dev/midistat → live kevent add/delete mechanics exercised on the real guest syscalls, guest stays alive (midistat has no kqfilter, ENODEV on EV_ADD — proving only the missing MIDI hardware blocks the live trigger).

The harness copies the queue macros and knote_remove() verbatim from sys/sys/queue.h:191-219 and sys/kern/kern_event.c:1902-1909 (LWKT pool token omitted — an SMP exclusivity primitive irrelevant to single-threaded list semantics) and midi_filter_detach() verbatim from midi.c:932-941.

Fix

fix.diff — split the detach callback per filter (mirrors the tty(4) idiom). midi_kq_model fixed mode models the patched behavior: clean.

VERDICT — DF-4283

Status: reproduced (model harness on the audit guest) / kernel panic, local DoS Impact: dos — deterministic NULL-pointer-dereference kernel panic Confidence: certain

Root cause (source-certain)

1. midi_kqfilter() [sys/dev/sound/midi/midi.c:901-930] selects exactly one klist per knote: EVFILT_READ → &m->rkq.ki_note, EVFILT_WRITE → &m->wkq.ki_note, then knote_insert(klist, kn).
2. The shared detach callback midi_filter_detach() [midi.c:932-941] does: c knote_remove(rklist, kn); knote_remove(wklist, kn); i.e. it also removes the knote from the list it was never in.
3. knote_remove() [sys/kern/kern_event.c:1902-1909] calls SLIST_REMOVE, which [sys/sys/queue.h:208-219] walks the list to find the element with no membership check: c struct type *curelm = SLIST_FIRST((head)); while (SLIST_NEXT(curelm, field) != (elm)) curelm = SLIST_NEXT(curelm, field); When the element is absent, curelm walks off the end (NULL) and SLIST_NEXT(curelm, ...) dereferences NULL.
4. Detach runs whenever the knote goes away: EV_DELETE [kern_event.c:1365-1368] and kqueue teardown / process exit [kern_event.c:706-708] both call knote_detach_and_drop() → f_detach(kn).

Net: an EV_ADD followed by any detach of a midi fd knote = page fault on the kernel unmapped low page = panic. tty(4) shows the correct per-list idiom [sys/kern/tty.c:1308-1314, 1334-1340].

Reachability

• /dev/midiN.M is created mode 0666 [midi.c:364-366] — no privileges needed once the node exists.
• The node exists only when a driver calls midi_init(); the sole in-tree caller chain is snd_emu10kx → mpu401_init() [emu10kx-midi.c:201 → mpu401.c:185 → midi_init], i.e. SoundBlaster Live!/Audigy PCI audio. Verified on the audit guest: kldload sound succeeds, /dev/midistat (0666) appears, no /dev/midi* nodes are possible (no EMU PCI device under QEMU). So the live kernel trigger is hardware-gated on this guest but deterministic on any host with an emu10kx card and the standard module autoload.

Verification performed (this run)

1. Model harness midi_kq_model (built + run on the guest, gcc 8.3, DragonFly 6.5-DEVELOPMENT): queue macros copied verbatim from queue.h:191-219, knote_remove() verbatim from kern_event.c:1902-1909 (pool-token omitted), midi_filter_detach() verbatim from midi.c:932-941. - mode empty (foreign list empty): SIGSEGV at address 0x0 — the immediate SLIST_NEXT(NULL) deref. exit 99. - mode peer (foreign list holds a different knote): SIGSEGV at address 0x0 — walk-to-end then NULL deref. exit 99. - mode fixed (fix.diff split-detach semantics): clean, exit 0. - mode control (membership holds): clean — proves the macro itself is sound when used correctly. See run.log lines: "[empty] SIGSEGV at faulting address 0x0", "[peer] SIGSEGV at faulting address 0x0".
2. Live syscall control kq_trigger /dev/midistat on the guest: real kevent(2) EV_ADD/EV_DELETE + kqueue-teardown-with-attached-knote against the only live midi-family node. EV_ADD → ENODEV (midistat has no d_kqfilter), no crash, guest alive — the trigger mechanics are real; only the absent MPU hardware (i.e. the midi fd) blocks the live panic.

Why not a live kernel panic

QEMU has no EMU10K1/EMU10K2 model; snd_emu401/ISA sound does not exist in this tree (sys/dev/sound/isa absent); no other driver calls midi_init. The kernel path is therefore unreachable on this guest — a QEMU limitation, not a property of the bug (any SB Live!/Audigy host panics on first kqueue use of its midi device by any local user).

Exploit-chain assessment

Primitive is a NULL-dereference read (curelm->sle_next with curelm == NULL); SLIST_REMOVE never writes through the NULL cursor before faulting (SLIST_REMOVE_AFTER(curelm,...) runs only after a successful walk). No controlled write, no info leak — impact ceiling is denial of service (panic), but it is instant, repeatable, and unprivileged on affected hardware.

Fix validation

fix.diff splits midi_filter_detach into per-filter callbacks (mirroring tty.c). Model mode fixed re-runs the identical scenario with patched semantics: clean removal, no foreign-list walk, exit 0 (run.log "[fixed] clean: knote removed from its owning list"). A kernel-level patched-kernel build cannot be exercised on this guest for the same hardware reason as above.

Bottom line

Real, deterministic, unprivileged-kernel-panic bug in the midi(4) kqueue path, certain at source level and demonstrated by a line-faithful harness on the audit guest; live kernel triggering requires emu10kx-class audio hardware (not emulatable in QEMU).

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.