DF-3999 — Record channels mis-mapped to play hw numbers: OOB rbuf reads before/after the buffer on every record pass

File: sys/dev/sound/pci/envy24ht.c (pass 2) Class: kernel info leak (unprivileged, deterministic) + broken record routing.

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'

Expected (baseline) — cases [A]/[B]

[A] 1st rec ch (num=1, slot=-8, offset=0), r32sl:
  [A] user stream received 8 samples from BEFORE rbuf, 0 from PAST rbuf end
         first leaked: data[0] = 0xabadbe08 (kernel-heap marker)
[B] 5th rec ch (num=10, slot=+10, offset=0), r32sl:
  [B] user stream received 0 samples from BEFORE rbuf, 10 from PAST rbuf end
         first leaked: data[8182] = 0xdeadfe00 (kernel-heap marker)

Fixed variant (emldmaht_harness_fixed.c, slot clamp applied): both cases 0.

Files

Same harness as DF-3998 (cases [A]/[B] are this finding); fix.diff is the slot clamp. Live /dev/dsp trigger hardware-gated (env.txt: envy24-pci-devs=0).

DF-3999 — VERDICT

Finding: envy24ht_pci_attach registers 1 play + (2+adcn) rec channels (envy24ht.c:2494-2505) but consumes the shared 11-entry envy24ht_chanmap[] (envy24ht.c:221-233) positionally: the single play channel gets hw num chanmap[0]=0 (PLAY_DAC1) and the rec channels get chanmap[1..2+adcn] = play channel numbers 1,2,3,4 followed by REC_MIX(10), REC_SPDIF(9) — never the REC_ADC1..4 numbers (5..8) the record emulators assume. envy24ht_r32sl/envy24ht_r16sl compute slot = (ch->num - ENVY24HT_CHAN_REC_ADC1) * 2 (envy24ht.c:1432, 1462; REC_ADC1 = 5), producing negative slots (−8,−6,−4,−2 for the first four rec channels) and slots ≥ +8 (+10, +8 for the 5th/6th) against a 2-entry interleaved frame (ENVY24HT_REC_CHNUM=2, rbuf = 8192 sample32_t entries). Result: every EMLDMARD on those channels reads kernel memory from BEFORE the record DMA buffer (negative index, up to 32 bytes before sc->rbuf) and/or past its end — unconditionally, at offset 0, on the FIRST record channel open — and copies it into the user's record stream.

Status: reproduced (verbatim-code harness on the guest; live trigger hardware-gated — no ICE1724 device in QEMU). Confidence: certain. Impact class on real hardware: kernel info leak (32 bytes before the 32 KB bus_dmamem_alloc rbuf + 40 bytes past its end per pass on the standard adcn=3 configuration), unprivileged, deterministic, on every record DMA pass of the affected channels. Independent of DF-3998 (present at offset 0), though DF-3998's offset widens the window.

Root cause (path:line)

• Registration/mapping mismatch:
• envy24ht.c:2494 pcm_register(dev, sc, 1, 2 + sc->adcn) (the designed 5 is commented out at 2493),
• envy24ht.c:2499 single pcm_addchan(... PCMDIR_PLAY ...) (the designed loop is commented out at 2498),
• envy24ht.c:2502-2505 rec addchan loop,
• envy24htchan_init envy24ht.c:1497 num = sc->chnum; and envy24ht.c:1512 ch->num = envy24ht_chanmap[num];.
• Slot formula assuming ADC numbering: envy24ht.c:1432 and envy24ht.c:1462 slot = (ch->num - ENVY24HT_CHAN_REC_ADC1) * 2; with ENVY24HT_CHAN_REC_ADC1 = 5 (envy24ht.h:164) while the rec channels actually carry num ∈ {1,2,3,4,10,9} → slot ∈ {−8,−6,−4,−2,+10,+8}.
• Accesses: envy24ht.c:1435-1436 (r32sl) and envy24ht.c:1465-1466 (r16sl): dmabuf[src * 2 + slot{,+1}].

For the standard board configuration (scfg=0x0b → adcn=3 → 5 rec channels, hw nums {1,2,3,4,10} → slots {−8,−6,−4,−2,+10}): - rec channels 1-4 (slots −8..−2): for src < 5 the index src*2 + slot is negative → reads up to 32 bytes BEFORE sc->rbuf (kernel heap preceding the DMA allocation) into the user stream, on every EMLDMARD pass, at offset 0, starting with the first channel. - rec channel 5 (slot +10): for src ≥ 4091 the index exceeds the last frame → reads up to 40 bytes PAST the rbuf end, every pass. - The E2PROM path (envy24ht_rom2cfg, arbitrary scfg byte) allows adcn=4 → 6 rec channels → additionally slot +8 (num 9).

Reproduction

• emldmaht_harness.c (shared with DF-3998) runs the verbatim r32sl against canary arenas sized exactly like rbuf:
• [A] first rec channel (num=1, slot=−8, offset=0): 8 samples from BEFORE rbuf land in the user stream (data[0] = 0xabadbe08 — full 32-bit kernel-heap marker words with S32_LE) — run.log.
• [B] 5th rec channel (num=10, slot=+10, offset=0): 10 samples from PAST the rbuf end (data[8182] = 0xdeadfe00) — run.log.
• Deterministic across run.2.log; identical arithmetic to what the kernel runs at every record interrupt.
• Fixed variant (slot clamp % ENVY24HT_REC_CHNUM, plus the DF-3998 index wraps): [A]/[B] report 0 leaked samples (fix_run.log).

Impact assessment

Unprivileged kernel heap disclosure, limited per-pass window (~72 bytes around rbuf) but repeating on every record DMA block and across all affected channels, complementary to DF-3998's larger window. Also a functional defect: all record channels are mis-routed (their PCM comes from the wrong slots / out of range), so recording on this hardware is broken in general — consistent with the driver being rarely exercised.

Fix

Minimal safety fix (fix.diff): clamp the record slot into the frame: slot = ((ch->num - ENVY24HT_CHAN_REC_ADC1) * 2) % ENVY24HT_REC_CHNUM; The full functional fix is restoring the designed registration (5 play channels, so rec channels consume chanmap[5..] = REC_MIX, REC_SPDIF, REC_ADC1..) together with a slot computation bounded to [0, ENVY24HT_REC_CHNUM); note even the designed mapping yields slots {+10,+8,0,2,4}, so the clamp is required either way for REC_MIX/SPDIF. Validated at harness level (fix_run.log: 0 leaks).

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.