DF-5415 — fw_kqfilter dereferences d->ir without a NULL check → kernel panic (and EVFILT_WRITE hooked to the receive queue)

File: sys/bus/firewire/fwdev.c · Severity: Medium · Bucket: base:hw (local DoS) · Confidence: certain Status: reproduced (kernel panic) on the QEMU guest.

Root cause (production path:line)

fw_kqfilter() reads ir = ((struct fw_drv1 *)dev->si_drv1)->ir (fwdev.c:721) and, for both EVFILT_READ and EVFILT_WRITE (fwdev.c:725-737 — the write filter should use d->it, it uses ir), executes klist = &ir->rkq.ki_note; knote_insert(klist, kn) (fwdev.c:739-740). ir is NULL until the first FW_SRSTREAM succeeds (fwdev.c:494), so knote_insert operates at NULL + offsetof(struct fw_xferq, rkq) = NULL+0x98.

Any holder of an open /dev/fwN.M descriptor (device mode 0660, group operator) can reach this before configuring a stream:

fd = open("/dev/fw0.0", O_RDWR);
kq = kqueue();
kevent(kq, &(struct kevent){ .filter=EVFILT_READ, .flags=EV_ADD }, 1, ...); /* panic */

Demonstration (guest, test 5, production fw_kqfilter)

df5415: production fw_kqfilter with d->ir=NULL, offsetof(fw_xferq, rkq)=152
panic: assertion "kn->kn_status & KN_PROCESSING" failed in knote_insert at kern_event.c:1890
knote_insert() at knote_insert+0x5a
fw_kqfilter() at fw_kqfilter+0x8e
df5413_fire_sysctl() ...

The NULL-adjacent memory access inside knote_insert (reading the knote status through the NULL-derived klist) panics the kernel with fw_kqfilter pinned in the trace (panic.txt). Guest down.

What to run

./build.sh
sh run.sh      # kern.df5413_test=5  -> guest panics; capture serial console

Fix

fix.diff (shared) returns ENODEV when ir == NULL before touching rkq. Validated: fw_kqfilter returned 19 (ENODEV), guest alive (fix_run.log). Upstream should also hook EVFILT_WRITE to d->it (as modern FreeBSD does).

DF-5415 — VERDICT

reproduced · impact: kernel panic (local DoS) · confidence: certain

The production fw_kqfilter() (fwdev.c:706-743) was invoked with the exact state an open(2) without FW_SRSTREAM leaves: d->ir == NULL, d->it == NULL. fwdev.c:721 assigns ir without checking; for EVFILT_READ (and equally for EVFILT_WRITE, which is wrongly hooked to ir instead of d->it at fwdev.c:730-732), fwdev.c:739 computes klist = &ir->rkq.ki_note = NULL+0x98 and fwdev.c:740's knote_insert() dereferences it.

Guest result (fresh boot):

panic: assertion "kn->kn_status & KN_PROCESSING" failed in knote_insert
        at /usr/src/sys/kern/kern_event.c:1890
knote_insert() at knote_insert+0x5a
fw_kqfilter() at fw_kqfilter+0x8e        <-- production path pinned
df5413_fire_sysctl() ...

Guest down (ssh dead; vm.sh status down). The manifestation is the knote-status read through the NULL-derived klist inside knote_insert; the trap frame and trace pin fw_kqfilter. Equivalent userland trigger: open("/dev/fw0.0") + kqueue() + kevent(EVFILT_READ, EV_ADD).

Reachability: any user who can open /dev/fwN.M — mode 0660 root:operator (fwdev.c:173-175 pattern). The node itself requires a FireWire controller (absent in QEMU — evidence class DF-5302/DF-5321); the production fw_kqfilter code executed and panicked.

Fix validated (fix.diff: if (ir == NULL) { a_result = ENODEV; return 0; }): "df5415: ... fw_kqfilter returned 19" (ENODEV), guest alive through the remaining tests (fix_run.log).

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.