DF-4332 — hptmv read-only GUI ioctls walk array state with no driver lock (UAF race)

Files (walk sites under audit): sys/dev/raid/hptmv/gui_lib.c * get_array_flag :163-197 (pMember[i] derefs) * calc_rebuild_progress :208-224 * get_array_info/get_array_info_v2 :243-245, 265-267 * hpt_get_logical_devices :496 (while (pLogical->pParent) walk) * dispatcher: hpt_default_ioctl :1134-1447

Race counterpart (out-of-file, root cause of the missing serialization): sys/dev/raid/hptmv/ioctl.c:312-329 routes HPT_IOCTL_GET_ "directly" with no lock_driver(), and HPT_IOCTL_DELETE_ARRAY (ioctl.c:219-263 → hpt_delete_array → blob fDeleteArray) also never takes the driver lock, while the mutating ioctls (CREATE_ARRAY / SET_ / ADD_) do* run under lock_driver_idle (:357-371). gui_lib.c's own header states the contract plainly (gui_lib.c:36-37): "This implementation doesn't use any synchronization; the caller must assure the proper context when calling these functions" — the caller does not, for the whole read-only family and for DELETE_ARRAY.

Trigger (requires HighPoint RocketRAID 18xx hardware)

Two concurrent root sysctl writes to hw.hptmv.status (hptproc.c:614-617, gated by SYSCAP_NOSYSCTL_WR, kern_sysctl.c:1446):

• thread A: HPT_IOCTL_GET_DEVICE_INFO {id = array X} → get_array_info walks X->u.array.pMember[0..bArnMember-1] and copies VDEV_TO_ID(pMember) / ArrayName / flags to userspace;
• thread B: HPT_IOCTL_DELETE_ARRAY {id = X} → fDeleteArray frees X's member array tables (mArFreeArrayTable, cf. the mirrored free in gui_lib.c:802-809) and stamps.

Thread A then dereferences freed PVDevices: UAF read → panic, or — if the freed slab is untouched — copies kernel heap pointers (VDEV_TO_ID = truncated PVDevice) and stale slab contents out via hptproc.c:315.

Guest status — NOT REPRODUCIBLE HERE

The audit guest has no HighPoint/Marvell PCI device:

# pciconf -l | grep -icE "11ab|hpt"
0
# sysctl -n hw.hptmv.status
sysctl: unknown oid 'hw.hptmv.status'     # hpt_status OID registered from attach

With gIal_Adapter == NULL the ioctl path NULL-derefs before reaching gui_lib.c (already known: DF-1853). Verdict: inconclusive — hardware absent; the race is established by code inspection only.

Fix direction (not validated on this guest)

Serialize the read-only dispatch group and DELETE_ARRAY under the same lock_driver()/lock_driver_idle(pAdapter) regime as the mutating ioctls (one-line summary; a reviewed patch needs care: GET_* currently run lock-free by design comment ioctl.c:316).

DF-4332 — VERDICT

Status: inconclusive (hardware absent). Confidence in the code defect: likely.

Why inconclusive

The race requires (a) a HighPoint RocketRAID 18xx controller attached (gIal_Adapter != NULL), (b) at least one configured array, and (c) two concurrent privileged sysctl writes. The audit guest (QEMU, stock X86_64_GENERIC) has no such device — pciconf -l shows zero 11AB devices and the hw.hptmv.status OID is not even registered (it is created from the attach path via xhptregister_node, hptproc.c:612-619 + entry.c:98). Without an adapter the ioctl entry NULL-derefs long before gui_lib.c is reached — that crash is the already-known DF-1853 and is deliberately NOT reproduced here.

Code trace establishing the defect

1. hptproc.c:614-617 registers hw.hptmv.status RW; writes require SYSCAP_NOSYSCTL_WR (sys/kern/kern_sysctl.c:1446-1447) → root-only surface, consistent with DF-1529/1530/1531's threat model.
2. hptproc.c:309-311 calls Kernel_DeviceIoControl per write, with no serialization between two concurrent writers.
3. ioctl.c:312-329: the read-only family (GET_CHANNEL_INFO / GET_LOGICAL_DEVICES / GET_DEVICE_INFO[_V2] / …) is forwarded to hpt_default_ioctl directly — the comment at :316 says "read-only ioctl functions can be called directly" — i.e. without the lock_driver_idle() that the mutating group gets at :357-371.
4. ioctl.c:219-263 (HPT_IOCTL_DELETE_ARRAY) → hpt_delete_array (:156-186) → blob fDeleteArray — also no lock held.
5. gui_lib.c:36-37 documents that gui_lib itself has zero synchronization. Its read paths dereference live structures freely: hpt_get_device_info:512-534 (mIsArray → get_array_info:230-249), get_array_flag:163-197 (pMember[i] derefs guarded only by NULL check), calc_rebuild_progress:208-224, hpt_get_logical_devices:496 (while (pLogical->pParent) unbounded parent walk).
6. fDeleteArray (blob, ioctl.c:183) tears down array tables (mArFreeArrayTable, the free pattern visible at gui_lib.c:802-809) — concurrent step 5 walks are then UAF reads.

Impact ceiling: kernel UAF read → panic (DoS), or limited kernel-heap info leak — get_array_info copies VDEV_TO_ID(pMember) (kernel addresses) and ArrayName bytes from freed/reused slab to the caller (hptproc.c:315 copyout). Root-triggerable from both sides; race window is a single ioctl. Severity Low.

What would falsify or confirm it

Confirm: two threads looping GET_DEVICE_INFO vs DELETE_ARRAY on a real 182x with one mirror array; expect panic in get_array_flag/get_array_info or pIds[] values leaking heap pointers after free. Falsify: if the blob's fDeleteArray defers all frees via DPC-to-completion under the caller's lock (it takes none, so unlikely), the race would be only against rebuild state, not lifetime.

Fix direction

Hold the driver lock across the read-only dispatch group and DELETE_ARRAY (mirroring ioctl.c:357-371), or refcount PVDevice lifetime for the GET_* walks. Not validated on this guest (no hardware); no fix.diff shipped.

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)