DF-3924 — fOsBuildSgl panics on CAM_DATA_PHYS passthrough CCBs (reachable kernel panic)

What

sys/dev/raid/hptmv/entry.c:2510-2541 (fOsBuildSgl, the pfnBuildSgl of every hptmv command, set at entry.c:2799):

if(logical) {
    if (ccb->ccb_h.flags & CAM_DATA_PHYS)
        panic("physical address unsupported");        /* :2517-2518 */
    if (ccb->ccb_h.flags & CAM_SCATTER_VALID) {
        if (ccb->ccb_h.flags & CAM_SG_LIST_PHYS)
            panic("physical address unsupported");    /* :2521-2522 */

A CAMIOCOMMAND CCB on /dev/passN with CAM_DIR_* + CAM_DATA_PHYS set (and data present) skips cam_periph_mapmem entirely — passsendccb only maps when (ccb->ccb_h.flags & CAM_DATA_PHYS) == 0 (sys/bus/cam/scsi/scsi_pass.c:565) — so the flag reaches the SIM unfiltered and the first READ/WRITE with a non-scatter data buffer executes panic().

CAM_SG_LIST_PHYS without CAM_SCATTER_VALID is likewise a panic, though the scatter+phys variant is handled earlier in OsSendCommand (entry.c:2852-2857).

Impact

Root/operator-triggerable kernel panic on any hptmv box (DoS); also the "correct" hardware-event-adjacent path: any kernel consumer that legitimately issues physical-address CCBs to this SIM would panic. Left-in debug panic, same family as DF-3921 (hpt_async "Here"). Severity Low (privileged trigger + hardware-gated), certainty certain.

Reproduce (needs RR1820 + root)

cc -o df3924 df3924.c && sudo ./df3924 <hptmv-pass-unit>
# vulnerable driver: immediate panic "physical address unsupported"

Fix

--- a/sys/dev/raid/hptmv/entry.c
+++ b/sys/dev/raid/hptmv/entry.c
@@ -2514,11 +2514,13 @@ fOsBuildSgl(_VBUS_ARG PCommand pCmd, FPSCAT_GATH pSg, int logical)
    if(logical) {
-       if (ccb->ccb_h.flags & CAM_DATA_PHYS)
-           panic("physical address unsupported");
+       if (ccb->ccb_h.flags & CAM_DATA_PHYS)
+           return FALSE;
        if (ccb->ccb_h.flags & CAM_SCATTER_VALID) {
-           if (ccb->ccb_h.flags & CAM_SG_LIST_PHYS)
-               panic("physical address unsupported");
+           if (ccb->ccb_h.flags & CAM_SG_LIST_PHYS)
+               return FALSE;

(returning FALSE funnels the command into the existing PIO/RETURN_NEED_LOGICAL_SG error handling instead of panicking; see fix.diff)

DF-3924 VERDICT

status: not_reproduced (hardware-gated) | impact observed: none (potential: privileged DoS panic) | source certainty: certain

Trace

• scsi_pass.c:565-568: passsendccb calls cam_periph_mapmem ONLY when CAM_DATA_PHYS is clear; a CAM_DATA_PHYS CCB is forwarded to the SIM as-is.
• entry.c:2799: every hptmv READ/WRITE gets pfnBuildSgl = fOsBuildSgl.
• entry.c:2517-2518 / 2521-2522: unconditional panic() when the flag is seen with a logical (mapped) buffer request.
• Trigger actor: root / SYSCAP_RESTRICTEDROOT through /dev/passN (see DF-3920 privilege analysis) on an hptmv target.

Not reproduced: audit guest has no RR1820 (env.txt); panic is unconditional at source, so the only uncertainty is reachability of the hardware, not the crash.

Fix validation

Hardware-gated; fix.diff replaces the panics with FALSE returns, which route the command to the existing PIO path / RETURN_NEED_LOGICAL_SG error handling (fDeviceSendCommand entry.c:1792-1805).

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.