PoC DF-1590: tws_cam.c firmware-controlled req_id OOB

Class: Heap OOB call + OOB struct deref Cited site: sys/dev/raid/tws/tws_cam.c:1163,1170,512-513,85,96

Reproduction status

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

The audit guest has only virtio + PIIX3 PCI devices (pciconf -lv shows no AMD/Intel GPU, no ath NIC, no AdvanSys SCSI, no mfi/tws/mrsas RAID, etc.), so the cited code path is not reachable at runtime on this guest.

The bug is confirmed at the source level by tracing the cited path:line in sys/dev/raid/tws/tws_cam.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

tws_intr_resp filters only TWS_INVALID_REQID=0xFFFF, then 1170 sc->reqs[req_id].cb(&sc->reqs[req_id]) NO upper-bound check vs tws_queue_depth (<=256). req_id is u16 from firmware DMA reply. tws_err_complete at 512-513 reads req_id from DMA sense header, NO check at all. tws_get_response extracts from firmware response. OOB req passed to handlers calling xpt_done(req->ccb_ptr) and kfree(req->data).

Realistic impact ceiling (on suitable HW)

arbitrary cb() call with OOB struct ptr as arg; arbitrary kfree of attacker-controlled address

Fix

In tws_intr_resp, treat req_id >= tws_queue_depth as invalid; in tws_err_complete, add the same check before indexing sc->reqs[].

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

How to validate the fix

scp -F dfbsd-qemu/config fix.diff dfbsd:/root/DF-1590.diff
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && patch -p1 --forward < /root/DF-1590.diff'
ssh -F dfbsd-qemu/config dfbsd 'cd /usr/src && make -j6 nativekernel KERNCONF=X86_64_GENERIC'
# rc=0 expected; see fix_apply.log + fix_build.log in this folder.

VERDICT — DF-1590: tws_cam.c firmware-controlled req_id OOB

Verdict

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

The bug is real and present in master DEV source at sys/dev/raid/tws/tws_cam.c:1163,1170,512-513,85,96, but the affected driver attaches only to hardware not present in the audit QEMU guest (only virtio+PIIX3 PCI devices, no AMD/Intel GPUs, no ath NICs, no AdvanSys SCSI, no mfi/tws/mrsas RAID, etc.), so it cannot be live-triggered here. The fix.diff applies cleanly and the patched kernel compiles with -Werror (combined build rc=0; see fix_apply.log).

Mechanism (cited path → primitive → effect)

tws_intr_resp filters only TWS_INVALID_REQID=0xFFFF, then 1170 sc->reqs[req_id].cb(&sc->reqs[req_id]) NO upper-bound check vs tws_queue_depth (<=256). req_id is u16 from firmware DMA reply. tws_err_complete at 512-513 reads req_id from DMA sense header, NO check at all. tws_get_response extracts from firmware response. OOB req passed to handlers calling xpt_done(req->ccb_ptr) and kfree(req->data).

Reachability on this guest

No — sys/dev/raid/tws/tws_cam.c:1163 is in a driver/module that only attaches to hardware absent from the audit guest. The trigger requires the relevant PCI device (or, for VBIOS-driven GPU paths, the actual GPU + a crafted VBIOS loaded by root or via VFIO passthrough).

Phase 6 — escalation potential

This is a Heap OOB call + OOB struct deref 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).

Realistic impact ceiling on suitable HW: arbitrary cb() call with OOB struct ptr as arg; arbitrary kfree of attacker-controlled address.

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 the combined make -j6 nativekernel KERNCONF=X86_64_GENERIC build (kernel build rc=0; see manifest.json).
• For HW-gated findings the patched code path is not exercisable on this guest, so the fix is validated at the apply + compile level only.

Fix approach: In tws_intr_resp, treat req_id >= tws_queue_depth as invalid; in tws_err_complete, add the same check before indexing sc->reqs[].

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.