DF-2270 — Missing bounds check on cesr_element_type in chgetelemstatus

File: sys/bus/cam/scsi/scsi_ch.c:1066-1200 Claim: chet = cesr->cesr_element_type (u_int16_t from user, values 4..65535) indexes int sc_firsts[4] / int sc_counts[4] with NO bounds check — the only ioctl handler in the driver without one — so the range check that gates cesr_element_count is evaluated against out-of-bounds heap words.

Verdict: REPRODUCED — OOB-read-driven validation bypass + guest-killing DoS

Verified on the CAM verbatim-interposition harness kernel: the byte-identical scsi_ch.c compiled into a DragonFly 6.5-DEVELOPMENT INVARIANTS kernel (rig/, sha256-gated check_verbatim.sh), a fabricated ch_softc placed inside a 512KB 0x5a-canary M_DEVBUF region, and a real /dev/ch0 created by the drivers own make_dev call. All tests drove the REAL chioct/ chgetelemstatus code through a real userland ioctl(2) on /dev/ch0.

Reproduce

cd rig
./build.sh            # push harness, gen TU, nativekernel, install, reboot
./run_tests.sh        # baseline suite (run_all.log / run_dmesg.log)
./run_hang.sh         # DESTRUCTIVE 4GiB M_INTWAIT test (hang_serial.log)
./make_fix.sh         # apply fix227x_all.diff on guest /usr/src
./build.sh            # fixed kernel
./run_fixed.sh        # A/B suite (run_fixed_all.log)

Expected (vulnerable kernel)

• ch_user ges 1 0 16 -> SUCCESS (in-range control works)
• ch_user ges 1 0 17 -> EINVAL (in-range validation works)
• ch_user ges 8 0 300 -> SUCCESS (element type 8 does not exist; the gate consulted sc_counts[8] = canary 0x5a5a5a5a = 1515870810)
• ch_user ges 1000 0 1000 -> SUCCESS (OOB read +4000 bytes past array)
• sysctl debug.dfch.map=1 prints exactly which OOB words authorize (canary) and which reject (sc_movemask bytes read as -1)
• sysctl debug.dfch.hang=1 (or a userland ges 8 0 65535 against a target reporting desclen 0xffff) computes size = 0xffff*0xffff+16 ≈ 4GiB and calls kmalloc(size, M_DEVBUF, M_INTWAIT):

DFH2270HANG: thread calling REAL chgetelemstatus() with type=8 count=65535 ...
DFH2270HANG: *** THREAD DID NOT RETURN within 8s: kmalloc(..., M_INTWAIT) of
~4GiB is stuck (watchdog fired; system must be reset)
pagedaemon: WARNING! Continuous paging for 1 minutes
pagedaemon: WARNING! Continuous paging for 1 minutes

after which the guest dies outright (ssh banner timeout, force-kill + reset).

Expected (fixed kernel)

• ges 8 0 300 and ges 1000 0 1000 -> EINVAL (gate added)
• ges 1 0 16 still SUCCESS, ges 1 0 17 still EINVAL (no regression)
• the same debug.dfch.hang=1 direct trigger returns instantly: chgetelemstatus RETURNED (no hang), RES ccbs=0

Impact ceiling

Privesc: NONE. /dev/ch0 is created UID_ROOT/GID_OPERATOR 0600 (scsi_ch.c:364-366) and chopen requires SYSCAP_RESTRICTEDROOT (scsi_ch.c:396) — verified crw------- root operator on the guest. Only root reaches the bug. Consequence = root-triggerable kernel heap OOB read (4..65535 ints past two arrays, values used as authorization AND as SCSI element addresses in the CDB, scsi_ch.c:1100/1137) plus the demonstrated guest-killing M_INTWAIT allocation hang. Medium severity as filed stands.

Fix

fix.diff (= rig/fix2270.diff, included in rig/fix227x_all.diff): the exact sibling idiom from chmove (scsi_ch.c:805):

    /* perform argument checking */
+   if (cesr->cesr_element_type > CHET_DT)
+       return (EINVAL);

Files

• rig/ full harness (df_pre.c / verbatim scsi_ch.c / df_post.c, gen.sh, check_verbatim.sh, build.sh, make_fix.sh, run_*.sh, ch_user.c)
• run_all.log, run_dmesg.log — baseline suite
• hang_serial.log, hang_pagedaemon.log — destructive DoS run (serial)
• hang_iteration1.txt — harness-artifact panic of iteration 1 (honesty)
• run_fixed_all.log, run_fixed_dmesg.log — A/B on the fixed kernel
• fix.diff — the one-hunk fix
• env.txt, verdict.json, manifest.json

DF-2270 — VERDICT

Status: REPRODUCED (dos, certain)

The missing bounds check is real, is the outlier in its own file, and the full consequence chain was reproduced mechanically on a stock INVARIANTS DragonFly 6.5-DEVELOPMENT guest with the byte-identical driver code compiled into the kernel (CAM verbatim-interposition rig, rig/).

Root cause (line-accurate)

chgetelemstatus() (sys/bus/cam/scsi/scsi_ch.c:1053):

• :1066 int chet = cesr->cesr_element_type; — u_int16_t from the copied-in ioctl struct; user-controlled 0..65535. NO bounds check follows.
• :1077-1079 the only range gate: c if ((softc->sc_counts[chet] - cesr->cesr_element_base) <= 0 || (cesr->cesr_element_base + cesr->cesr_element_count) > softc->sc_counts[chet]) return (EINVAL); sc_counts is int sc_counts[CHET_MAX + 1] = int[4] (scsi_ch.c:158-159). For chet 4..65535 the gate is evaluated against out-of-bounds heap words (twice — the array is read in both clauses).
• :1100 and :1137-1138 softc->sc_firsts[chet] — two more OOB reads whose values are written into the READ ELEMENT STATUS CDB sent to the device (element address fully heap-derived).
• :1120-1122 size = 8 + 8 + desclen * cesr_element_count with the count that the OOB word just authorized.
• :1129 kmalloc(size, M_DEVBUF, M_INTWAIT).

Every sibling handler checks: chmove :805, chexchange :859, chposition :924, chsetvoltag :1261 (if (xxx_type > CHET_DT) return (EINVAL/ENODEV)). chgetelemstatus is the only one that does not.

Mechanical evidence

Rig: fabricated ch_softc zeroed at offset 256KB of a 512KB M_DEVBUF region filled with 0x5a; periph + make_dev(&ch_ops, ..., UID_ROOT, GID_OPERATOR, 0600, "ch%d", 0) exactly as chregister does (:364-366); fake CAM transport answers MODE SENSE (element address page 0x1d: firsts 0x1000/0x2000/0x3000/0x4000, counts 2/16/2/4; cap page 0x1f) and READ ELEMENT STATUS. Tests drove the REAL code through real userland ioctl(2) on /dev/ch0.

1. OOB map (sysctl debug.dfch.map=1, run_dmesg.log): chet 0..3 in-range; chet 4-5 read sc_movemask/sc_exchangemask bytes as 0xffffffff (-1, gate rejects); chet 6 reads settledelay+pad (0); chet >= 7 reads the canary 0x5a5a5a5a (1515870810) — the gate ACCEPTS any base/count for a nonexistent element type.
2. Validation bypass through the real device (run_all.log): - ges 1 0 16 -> SUCCESS (control, 16 statuses returned) - ges 1 0 17 -> EINVAL (control: in-range validation works) - ges 8 0 300 -> SUCCESS: 300 element statuses returned for element type 8, authorized solely by the OOB canary word - ges 1000 0 1000 -> SUCCESS (OOB read 4000 bytes past the array) - ges 4 0 1 -> EINVAL (heap-dependent: movemask bytes as -1)
3. M_INTWAIT consequence (hang_serial.log / hang_pagedaemon.log, captured on the serial console): the same call with count=65535 and a target desclen of 0xffff computes size = 0xffff*0xffff+16 ≈ 4GiB; kmalloc(..., M_DEVBUF, M_INTWAIT) never completes: DFH2270HANG: *** THREAD DID NOT RETURN within 8s ... (watchdog fired) pagedaemon: WARNING! Continuous paging for 1 minutes pagedaemon: WARNING! Continuous paging for 1 minutes The guest then died outright (ssh banner exchange timeout; the VM had to be force-killed and reset). sysctl run_rc=124. This is a guest-killing local DoS from a single ioctl. (Iteration 1 of this test panicked on a harness calling-convention artifact — kthread omitted cam_periph_lock — documented in hang_iteration1.txt and fixed; iteration 2 is the valid evidence.)
4. OOB-derived CDB content: with chet=8 the fake transport received READ ELEMENT STATUS with sea=0xffff (sc_firsts[8] OOB read) — the element address handed to the device is heap garbage (visible in rig transport counters).

Privesc assessment (team directive)

CLOSED — no unprivileged escalation: - /dev/ch0 is crw------- root operator (make_dev at scsi_ch.c:364-366; observed live on the guest, run_all.log). Only uid 0 can open it. - chopen independently requires SYSCAP_RESTRICTEDROOT (scsi_ch.c:396) — verified present in the verbatim code compiled here. - The OOB reads are reads; no write primitive exists in this function (the kmalloc target is fresh memory; user_data/data writes are driver-internal). The impact is authorization-from-garbage + DoS. Medium severity (privileged-user DoS + heap-dependent OOB read in a default-config-reachable driver) is the correct ceiling.

Fix validation (A/B)

fix.diff (one hunk, the chmove idiom at :805 applied to chgetelemstatus, placed right after /* perform argument checking */):

• vulnerable: ges 8 0 300 SUCCESS, ges 1000 0 1000 SUCCESS, hang test kills the guest
• fixed (run_fixed_all.log): ges 8 0 300 EINVAL, ges 1000 0 1000 EINVAL, ges 1 0 16 SUCCESS, ges 1 0 17 EINVAL (no regression), and the identical direct-call hang trigger returns instantly: DFH2270HANG: chgetelemstatus RETURNED (no hang), RES ccbs=0.

fix_status: fixed.

Honest notes

• The debug.dfch.hang trigger calls the real chgetelemstatus with a kernel-side cesr after taking the periph lock exactly as chioctl does; the userspace ges path (real ioctl) demonstrates the same gate bypass without any harness shortcut.
• The first baseline rig iteration had a shim bug (MODE SENSE guard len >= 64 vs actual param_len 30) that zeroed the real counts; fixed and the full suite re-run — the bypass results were identical across both iterations (they never depended on the in-range values).

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.