DF-3998 — Unclamped phase offset in the envy24ht DMA emulators (DF-3996 twin)

File: sys/dev/sound/pci/envy24ht.c (pass 2) Class: kernel memory disclosure (record direction, unprivileged) + latent kernel heap OOB write (play direction) + 1-element OOB write past ch->data.

Reproduce

scp -F dfbsd-qemu/config emldmaht_harness.c dfbsd-maxx:/tmp/
vm.sh run_user 'cc -O2 -Wall -o /tmp/emldmaht_harness /tmp/emldmaht_harness.c && /tmp/emldmaht_harness'
vm.sh run_user '/tmp/emldmaht_harness hard'     # guard-page proof
# fixed variant:
vm.sh run_user 'cc -O2 -Wall -o /tmp/emldmaht_fixed /tmp/emldmaht_harness_fixed.c && /tmp/emldmaht_fixed && /tmp/emldmaht_fixed hard'

Expected (baseline)

[C] 2nd rec ch (num=2, slot=-6) START: ptr=4087 blk=8 -> offset=4088 (ssize=2048)
  [C] user stream received 12 samples from BEFORE rbuf, 1 from PAST rbuf end
         first leaked: data[17] = 0xbe06 (low half of kernel-heap ...)
         data-side OOB write: data16[8192] = 0xfee9 (one element past ch->data)
[D] play twin p16sl (LATENT, 2nd play ch): offset=4064 -> 2 sample32 entries
    written past pbuf end, first at +130024 bytes (value 0xb9b90000)
HARD: SIGSEGV at first OOB read past rbuf end (offset=4088) - arithmetic proven

Fixed variant: all counts 0, no fault (fix_run.log).

Files

• emldmaht_harness.c — verbatim driver code + trigger-offset formula
• emldmaht_harness_fixed.c — same code with fix.diff applied (+DF-3999 slot clamp)
• build.log / run.log / run.2.log / run.hard.log / fix_run.log / env.txt
• fix.diff — git-apply-able fix against sys/dev/sound/pci/envy24ht.c

Live /dev/dsp trigger is hardware-gated: the QEMU guest has no ICE1724 (1412:1724) device (env.txt: envy24-pci-devs=0). The harness runs the exact kernel constants and verbatim code paths; the arithmetic is deterministic.

DF-3998 — VERDICT

Finding: envy24ht(4) carries the identical DF-3996 emldma defect: every DMA-emulator function forms its ring index as dst = src/2 + ch->offset (play) / src = dst/2 + ch->offset (rec) and performs the FIRST loop access BEFORE the %= dsize/%= ssize wrap, so whenever src/2 + offset >= dsize (rec: >= ssize) the access lands past the shared DMA buffer. The phase offset comes from envy24htchan_trigger's second-same-direction-channel START branch (envy24ht.c:1720-1726), same formula as envy24.c:1810.

Status: reproduced (verbatim-code harness on the guest; live /dev/dsp trigger hardware-gated — no ICE1724 PCI device in QEMU). Confidence: certain. Impact class on real hardware: kernel heap disclosure (record direction) — the record direction is directly reachable unprivileged; the play-direction OOB write is present in the code but gated behind a second PLAY channel, which the driver does not register (see below), so on the driver as shipped it is latent.

Root cause (path:line)

• envy24htchan_trigger PCMTRIG_START else-branch, sys/dev/sound/pci/envy24ht.c:1721-1723: ch->offset = ((ptr / ch->blk + 1) * ch->blk % (ch->size / 4)) * 4 / ch->unit; executed when sc->run[slot] != 1 after sc->run[slot]++ (1714) — i.e. for every same-direction channel after the first.
• envy24ht_r16sl envy24ht.c:1459 src = dst / 2 + ch->offset; then 1465-1466 read dmabuf[src * 2 + slot{,+1}] BEFORE src %= ssize (1470).
• envy24ht_r32sl 1429 / 1435-1436 / 1440 — same.
• envy24ht_p32sl 1324 / 1330-1331 / 1333, envy24ht_p16sl 1357 / 1366-1367 / 1375, envy24ht_p8u 1399 / 1405-1406 / 1408 — play twins.
• Buffers: sc->rbuf = ENVY24HT_REC_BUFUNIT(8)*4096 = 32768 B = 8192 sample32_t entries, sc->pbuf = 131072 B = 32768 entries (envy24ht.c:2160-2161, allocated 2171-2186 via bus_dmamem_alloc).

Reachability analysis (what is and is NOT reachable as shipped)

• The driver registers 1 play + (2+adcn) rec channels (envy24ht.c:2494-2505; adcn = ((scfg & 0x0c)>>2)+1, standard boards scfg=0x0b → adcn=3 → 5 rec channels). The offset branch requires sc->run[slot] != 1 — for PLAY that needs 2 running play channels; only 1 exists, and chn_start() refuses to re-START a running channel (sys/dev/sound/pcm/channel.c:697-701 CHN_STARTED(c) guard) → the play-direction OOB write (p8u/p16sl/p32sl) is unreachable on the driver as currently registered, i.e. LATENT — it goes live the moment the commented-out 5-play-channel registration (envy24ht.c:2493,2498) is restored, which the code comments show was the design.
• The record direction has 3-6 channels: the SECOND rec channel's PCMTRIG_START runs the offset branch unconditionally. r16sl with S16_LE gives ssize = ch->size/8 = 2048 while the offset formula scales with ch->size/4 → attacker-chosen ptr (observable via SNDCTL_DSP_GETIPTR on the running first rec channel) + user blocksize (SNDCTL_DSP_SETFRAGMENT) yields offset up to ~4088, and freeptr (how many bytes the user has consumed) sets dst/2 — src = dst/2 + offset reaches 8183 vs ssize 2048 → first access reads rbuf[16360..16361], 32672 bytes PAST the 32 KB record DMA buffer, into the user's record stream (read() on /dev/dsp). One OOB read pair per EMLDMARD/START; leaks the low 16 bits (S16_LE) or the full 32 bits (S32_LE) of each adjacent kernel word.
• Data-side edge: with freeptr at maximum, data[dst+1] writes one element (2-4 bytes) past the kmalloc'd ch->data (M_ENVY24HT, ch->size bytes) — observed in the harness as data16[8192] write.

Reproduction

• Guest: DragonFly 6.5-DEVELOPMENT (env.txt), no 1412:1724 PCI device (envy24-pci-devs=0) → live trigger impossible on this VM.
• emldmaht_harness.c runs the five emldma functions, the trigger offset formula and gethwptr bounds VERBATIM against canary arenas sized exactly like pbuf/rbuf. Results (run.log, deterministic across run.2.log):
• [C] second rec channel (num=2), ptr=4087, blk=8 (user blocksize 16), freeptr max → offset 4088 → 1 sample pair read from +32672 B past rbuf end into the user stream (0xFEE9 = low half of the kernel-heap marker 0xDEADFEE9); 12 additional before-rbuf samples from the periodic src %= ssize wrap landing on src<3 with slot −6 (that part is the DF-3999 slot defect, amplified by the offset); data-side 1-element write past ch->data with the leaked kernel value.
• [D] play twin: offset 4064 → first write at +130024 B past the 128 KB pbuf with the user's PCM payload 0xB9B90000 (S16_LE) — the write primitive, latent as described above.
• hard mode (run.hard.log): rbuf sized exactly against a PROT_NONE guard page → SIGSEGV on the FIRST OOB read — the arithmetic is exactly what the kernel would run against its bus_dmamem allocation.
• Fixed variant (fix.diff semantics applied): 0 leaked samples, 0 OOB writes, no fault (fix_run.log).

Exploit chain (real hardware)

open /dev/dsp0.r0 (first rec channel), start recording → open .r1, SETFMT S16_LE/S32_LE, SETFRAGMENT for the chosen blk, consume bytes to set freeptr, observe r0 hwptr via SNDCTL_DSP_GETIPTR, trigger r1 START → ch->offset computed (up to 4088/2047 by format) → each EMLDMARD leaks a 32-bit kernel word from up to ~32 KB past the 32 KB record DMA buffer into the user's record stream; retrigger/re-open varies the offset → repeatable kernel heap disclosure from an unprivileged user (0666 /dev/dsp clones). The complementary play-direction primitive (attacker-controlled 32-bit writes up to ~130 KB past the 128 KB play DMA buffer with S32_LE) is currently dormant — it activates for any build/patch that restores the designed 5-play-channel registration, at which point this becomes the DF-3996 privesc-grade chain verbatim. Fix both now.

Fix

fix.diff — wrap the phase-adjusted index before the first access in all five emldma functions (play: dst = (src/2 + ch->offset) % (ch->size/4|8); rec: src = (dst/2 + ch->offset) % (ch->size/8)), plus even-alignment of the data-side index so the (src, src+1)/(dst, dst+1) pair can never straddle the end of ch->data. Validated at harness level: baseline leaks + hard-mode fault vs 0/0/no-fault after the fix.

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.