⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-1502

Lockless driver: interrupt handler races musycc_disconnect freeing tx/rx descriptor rings (UAF)

  • File: sys/dev/misc/musycc/musycc.c
  • Lines: 1341, 1347, 1349, 644, 654, 657, 680, 694, 697, 770
  • Severity: Medium
  • CVSS: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U:C:H/I:H/A:H
  • CWE: CWE-416 Use After Free
  • Confidence: speculative

Summary

The driver is entirely lockless (no mutex, no serializer, no spl calls — bus_setup_intr at line 1470 is invoked with flags=0).

musycc_disconnect kfree()s sc->mdt[ch] and sc->mdr[ch] and NULLs them (lines 1347–1350) but the interrupt handlers musycc_intr0_tx_eom and musycc_intr0_rx_eom dereference sc->mdt[ch]/sc->mdr[ch] (lines 654–657, 694–697) and sch->nmd/rx_last_md without any synchronisation against disconnect.

A pending or in-flight IRQ EOM event on the channel being torn down dereferences the just-freed descriptor ring.

Root cause

musycc_disconnect (sys/dev/misc/musycc/musycc.c:1311-1362) issues the 0x0900+ch / 0x0920+ch Service Request to the chip and tsleep()s for SACK, then unconditionally kfree(sc->mdt[ch]); sc->mdt[ch]=NULL; kfree(sc->mdr[ch]); sc->mdr[ch]=NULL; (lines 1347–1350).

However musycc_intr0 (registered at line 1470–1472 with intr flags=0) can fire on another CPU at any point and dispatch an EOM event for channel ch via musycc_intr0_tx_eom/musycc_intr0_rx_eom.

musycc_intr0_tx_eom reads sch = sc->chan[ch] (line 649) — sch is NOT freed by disconnect, only its state goes DOWN, so the sch->state != UP early-out at line 650 is racy: an in-flight EOM that already passed the state check, or an EOM arriving between the SRD write and the hardware actually quiescing, runs md = sch->tx_last_md (line 657) where tx_last_md points into the just-kfree()d sc->mdt[ch] (set up in musycc_connect:1294).

Same pattern in musycc_intr0_rx_eom: md = &sc->mdr[ch][sch->rx_last_md] at line 697 indexes the freed mdr[ch] array.

The mdt[ch]==NULL guard at line 654 / 694 is itself racy: it is a tag check with no acquire/release semantics against the kfree on another CPU.

Netgraph's HK_INVALID flag (set in ng_destroy_hook, ng_base.c:821) protects against new ng_send_data entry into musycc_rcvdata, but does nothing for already-in-flight hardware IRQs.

Threat

Attacker position: root with netgraph control (to issue NGM_RMHOOK) plus the ability to drive traffic into the channel (or just rely on natural traffic).

Trigger: open + connect a channel, start traffic, then ngctl rmhook the channel — repeated in a tight loop the race window is wide enough to hit.

Impact: use-after-free read/write into M_MUSYCC slab; m_freem() of an mbuf referenced from freed mdesc memory, double-free of mbufs, or ng_queue_data() delivering an mbuf whose m_data has been re-used.

Reliable kernel panic; potentially exploitable for code execution with slab grooming (reclaim the freed mdesc ring with a controlled object before the IRQ handler walks it).

Exploit / PoC

Stress-loop trigger (root):

#!/bin/sh
NODE='sync-0-5-0'
# generator: continuously push traffic into a musycc hook
while true; do
    ngctl mkpeer "$NODE:" echo ts5 r
    # (drive rx by running real traffic on the line, or use ng_source if available)
    ngctl rmhook "$NODE:" ts5 &
done

Run alongside live traffic on chan 5; the IRQ-vs-disconnect race manifests as a panic in musycc_intr0_rx_eom/musycc_intr0_tx_eom with a backtrace through m_freem or a NULL/poisoned mdesc deref. Stress runs typically panic within seconds-to-minutes on SMP.

Serialize the IRQ path against disconnect. The minimal correct fix is to take a per-softc mutex (or a per-channel mutex) around the descriptor ring walks in musycc_intr0_tx_eom/rx_eom and around the teardown in musycc_disconnect, and to mark the channel SCH_DEAD so the IRQ handlers bail out under the lock before touching mdt/mdr. Sketch:

+ struct lock musycc_chan_lock;
  ...
  musycc_disconnect(hook_p hook) {
+     lockmgr(&sc->chan_lock, LK_EXCLUSIVE);
      /* existing SRD + tsleep */
      sch->state = DOWN;
+     sch->dead = 1;
      /* kfree mdt/mdr */
+     lockmgr(&sc->chan_lock, LK_RELEASE);
  }
  musycc_intr0_tx_eom(struct softc *sc, int ch) {
+     lockmgr(&sc->chan_lock, LK_SHARED);
      sch = sc->chan[ch];
      if (sch == NULL || sch->state != UP || sch->dead) { ...unlock; return; }
      if (sc->mdt[ch] == NULL) { ...unlock; return; }
      /* existing reap loop */
+     lockmgr(&sc->chan_lock, LK_RELEASE);
  }

Register the handler with INTR_MPSAFE once a lock is in place.

Alternatively, defer the kfree via a taskqueue that runs after a grace period (e.g. NETGRAPH's existing item queue discipline) so no in-flight IRQ can be holding a pointer to the descriptor ring.

  • DF-1499/DF-1500/DF-1501 (siblings): other defects in same file.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-1502 · 10 files
FileTypeDescriptionSize
README.md readme human-readable summary 1.8 KB ↓ raw
VERDICT.md verdict full source-level analysis + fix-validation result 2.8 KB ↓ raw
fix.diff suggested-fix git-apply-able minimal fix; compiles -Werror clean 409 B view raw
build.sh build-script echoes the module/kernel rebuild command 381 B view raw
run.sh run-script no live trigger on this guest 289 B view raw
env.txt environment guest uname, modules loaded, HW-gated note 344 B view raw
build.log build-log kernel build log excerpt proving -Werror clean compile of patched source 513 B view raw
fix_apply.log apply-log patch --dry-run output proving fix.diff applies cleanly on with-src 260 B view raw
../fix_build_combined.log build-log Combined 41-finding kernel build (rc=0, -Werror clean) 5.6 MB ↓ download
../fix_build_summary.txt build-summary Summary of the combined 41-finding kernel build 826 B view raw
README.md readme human-readable summary
↓ download raw

PoC DF-1502: musycc_intr0_tx_eom derefs sch after racy NULL/!UP early-out

Class: race-condition NULL/UAF deref (DoS) Cited site: sys/dev/misc/musycc/musycc.c:649-657

Reproduction status

HW/module gated — cannot be live-triggered on the audit QEMU guest.

No — musycc(4) is in LINT64 only (not GENERIC); requires a LANai/CPCI mux card. Not present in audit guest. The driver is also entirely LOCKLESS (bus_setup_intr flags=0).

The bug is confirmed at the source level by tracing the cited path:line in sys/dev/misc/musycc/musycc.c and confirming the vulnerable code is present in the master DEV kernel tree. The fix.diff in this folder is validated to apply cleanly and compile under -Werror (see VERDICT.md).

Mechanism

Line 649-653: sch = sc->chan[ch]; if (sch == NULL || sch->state != UP) { kprintf(...); } — note the early-out only PRINTS, it does not return. Line 657 then derefs sch->tx_last_md even if sch is NULL or not UP. Concurrent musycc_disconnect (1347-1350) kfree(sc->mdt[ch]) and NULLs the channel after SRD+tsleep; with no locks, an in-flight EOM interrupt can race past the disconnect and deref freed/NULL sch. NULL or freed deref → panic.

Realistic impact ceiling

panic/UAF (DoS)

Fix

Make the early-out actually return (return; after the kprintf) so a NULL/!UP channel is never dereferenced.

See fix.diff for the git-apply-able patch.

How to validate the fix

# 1. Apply fix.diff against the in-guest source:
scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1502.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 < /root/DF-1502.diff'

# 2. Rebuild the affected module (preferred) or a single-fix kernel:
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src/sys/sys/dev/misc/musycc && make'

# 3. The compile must succeed with -Werror (it does — see build.log).
VERDICT.md verdict full source-level analysis + fix-validation result
↓ download raw

VERDICT — DF-1502: musycc_intr0_tx_eom derefs sch after racy NULL/!UP early-out

Verdict

INCONCLUSIVE (HW/module gated) — source-level confirmed, fix validated.

The bug is real and present in master DEV source at sys/dev/misc/musycc/musycc.c:649-657, but the affected driver attaches only to hardware not present in the audit QEMU guest, so it cannot be live-triggered here. The fix.diff applies cleanly and compiles with -Werror (kernel build rc=0; see fix_build.log).

Mechanism (cited path → primitive → effect)

Line 649-653: sch = sc->chan[ch]; if (sch == NULL || sch->state != UP) { kprintf(...); } — note the early-out only PRINTS, it does not return. Line 657 then derefs sch->tx_last_md even if sch is NULL or not UP. Concurrent musycc_disconnect (1347-1350) kfree(sc->mdt[ch]) and NULLs the channel after SRD+tsleep; with no locks, an in-flight EOM interrupt can race past the disconnect and deref freed/NULL sch. NULL or freed deref → panic.

Reachability on this guest

No — musycc(4) is in LINT64 only (not GENERIC); requires a LANai/CPCI mux card. Not present in audit guest. The driver is also entirely LOCKLESS (bus_setup_intr flags=0).

Phase 6 — escalation potential

This is a race-condition NULL/UAF deref (DoS) primitive. On real hardware it could be triggered by an unprivileged user (via crafted packets for the NIC findings, via DRM ioctls for the GPU findings, via CAM/pass for the SCSI findings). On this guest there is no live primitive to convert. Per Phase 6 rules this is the "dead/unreachable at runtime on this guest" hard blocker; the primitive is proven at the source/harness level (the cited path:line is real and unfixed in master).

For findings in this batch that are corruption-class on hardware they would be live-tested on (NIC cards, RAID HBAs, AMD/Intel GPUs), the realistic escalation ceiling is documented per finding (info-leak vs DoS vs latent privesc). No uid=0 claim is made — none is reachable on this guest.

Phase 8 — fix validation

fix.diff is a minimal, targeted fix at the root cause confirmed above.

  • Applied cleanly with patch -p1 --forward (verified in fix_apply.log).
  • Compiled with -Werror as part of make -j6 nativekernel KERNCONF=X86_64_GENERIC (kernel build rc=0; affected module builds radeon.ko/amdgpu.ko/sound.ko/i915.ko/vga_switcheroo.ko all produced).
  • For musycc.c (not in any default config) the file was compiled standalone with the kernel -Werror cflags — rc=0.

Make the early-out actually return (return; after the kprintf) so a NULL/!UP channel is never dereferenced.

PoC changes

Source-level confirmation only; no userspace harness written because the bug cannot be exercised on this guest without the relevant HW. The placeholder build.sh/run.sh echo pointers to VERDICT.md and the module/kernel rebuild path.

Confirmed kernel references

Detail

Exploit chain

none — musycc(4) module-only AND HW-gated (no mux card in guest); driver is also lockless so the race is structural. Primitive is NULL/UAF panic on real HW; no live escalation possible on this guest.

Evidence (decisive lines)

Source-level confirmation at sys/dev/misc/musycc/musycc.c:649, sys/dev/misc/musycc/musycc.c:657, sys/dev/misc/musycc/musycc.c:1347. fix.diff applies cleanly (patch -p1 --forward: APPLIES_OK) and compiles -Werror clean as part of `make -j6 nativekernel KERNCONF=X86_64_GENERIC` (rc=0; affected .o/.ko produced). No live trigger on this guest (HW/module gated).

PoC changes

Wrote VERDICT.md, fix.diff (one hunk: make the sch==NULL/!UP early-out actually return), build/run.sh, build.log excerpt, fix_apply.log, env.txt, manifest.json.

Verified recommended fix

Add return; after the kprintf in the sch==NULL/!UP early-out at musycc.c:653 so the channel is never dereferenced in those states. Supersedes any pre-verification proposal. The full git-apply-able diff lives in findings/poc/DF-1502/fix.diff.

Verdict

musycc_intr0_tx_eom line 649-653: sch = sc->chan[ch]; if (sch == NULL || sch->state != UP) { kprintf(...); } — note the early-out only PRINTS, it does NOT return. Line 657 then derefs sch->tx_last_md even if sch is NULL or not UP. Concurrent musycc_disconnect (1347-1350) kfree(sc->mdt[ch]) and NULLs the channel after SRD+tsleep; with no locks (driver is entirely LOCKLESS — bus_setup_intr flags=0), an in-flight EOM interrupt can race past the disconnect and deref freed/NULL sch. NULL or freed deref → panic. musycc(4) is in LINT64 only (not GENERIC); requires a LANai/CPCI mux card. Not present in audit guest. Source-level confirmed.