DF-1088 — CAM pass-through (/dev/passN) missing CCB flag validation

Build

cc -o df1088_trigger df1088_trigger.c

Run

# unprivileged (demonstrates the privilege gate)
./df1088_trigger

# privileged (demonstrates the CCB-shape bug)
su root -c ./df1088_trigger

Expected (bug present)

• Unprivileged: open /dev/pass0 fails with Permission denied (devfs mode 0600) — the trigger is privilege-gated.
• Root (unpatched kernel): CAMIOCOMMAND with CAM_DIR_IN | CAM_DATA_PHYS and cdb_len=255 returns 0 — the kernel forwarded the dangerous CCB to the SIM without stripping or rejecting the flags, and did not clamp cdb_len to IOCDBLEN (16). The signature line is: [root] BUG: kernel forwarded attacker physical pointer to SIM without rejection (DF-1088 present)

Expected (after fix)

• Root (patched kernel): CAMIOCOMMAND returns -1, errno=EINVAL — passsendccb rejects the dangerous flags / over-long CDB at the head of the function. Signature: [root] FIXED: kernel rejected dangerous CCB flags (DF-1088 patch present)

Static verification

sh verify.sh

runs 7 source-tree grep checks that pin the exact buggy line and constants.

Bug shape

passsendccb at sys/bus/cam/scsi/scsi_pass.c:565-568 gates cam_periph_mapmem() purely on (flags & CAM_DATA_PHYS) == 0 but never strips the flag and never rejects it; the kernel-internal XPT path (cam_xpt.c:1133) does reject CAM_DATA_PHYS for XPT_DEV_MATCH. A user-supplied CCB with CAM_DATA_PHYS therefore bypasses the cam_periph_mapmem useracc/MAXPHYS/bounce-buffer path and reaches the SIM with csio.data_ptr interpreted as a physical address for DMA. The same function also fails to clamp csio.cdb_len to IOCDBLEN (16) for inline CDBs, so cdb_len=255 makes the SIM read 255 bytes from the 16-byte cdb_bytes[] array, over-reading adjacent union ccb fields including the kernel msg_ptr / data_ptr.

Impact / preconditions

The device requires caps_priv_check_self(SYSCAP_RESTRICTEDROOT) and securelevel <= 1 to open (scsi_pass.c:308,335), and /dev/passN is mode 0600 in the default install. The bug is therefore not directly reachable by an unprivileged user on a default install; impact requires either jail-granted RESTRICTEDROOT with /dev/passN exposed, or a process already holding the RESTRICTEDROOT capability. The CVSS vector in the finding reflects this (AV:L/PR:L ...).

DF-1088 — No validation/stripping of dangerous user CCB flags in CAM pass

Verdict

REPRODUCED (privilege-gated runtime). The bug exists verbatim in sys/bus/cam/scsi/scsi_pass.c:565-568; a root-originated CAMIOCOMMAND with CAM_DIR_IN | CAM_DATA_PHYS and csio.cdb_len = 255 is accepted by the unpatched kernel (rc=0, three-of-three deterministic runs) — i.e. the dangerous CCB is forwarded to the SIM with the user's csio.data_ptr interpreted as a physical address and the CDB read length un-clamped. After the fix.diff is applied the same CCB returns EINVAL.

The trigger is gated behind caps_priv_check_self(SYSCAP_RESTRICTEDROOT) (scsi_pass.c:308) plus a default mode-0600 devfs node, so an unprivileged user cannot reach the bug on a default install. The finding's realistic impact (jail escape / securelevel bypass on hosts without IOMMU) requires a jail granted RESTRICTEDROOT with /dev/passN exposed, or an already-capable process. The passsendccb defect itself is real, confirmed deterministically, and closed by the fix.

Mechanism (confirmed by source trace and runtime)

passsendccb merges the user CCB into a kernel CCB via xpt_merge_ccb (scsi_pass.c:546) and then conditionally maps user buffers:

/* scsi_pass.c:565-568 — the bug */
if (((ccb->ccb_h.flags & CAM_DATA_PHYS) == 0)
 && (((ccb->ccb_h.func_code == XPT_SCSI_IO)
    && ((ccb->ccb_h.flags & CAM_DIR_MASK) != CAM_DIR_NONE))
  || (ccb->ccb_h.func_code == XPT_DEV_MATCH))) {
    ...
    error = cam_periph_mapmem(ccb, &mapinfo);
    ...
}

When the user sets CAM_DATA_PHYS (cam_ccb.h:84, 0x00200000): - The gate is false → cam_periph_mapmem is skipped entirely. - cam_periph_runccb (scsi_pass.c:600) still forwards the CCB through xpt_action to the SIM/HBA. - The SIM sees csio.data_ptr (cam_ccb.h:598) as a physical address (the flag's documented meaning) and DMAs to/from it. For CAM_DIR_IN the device response overwrites the attacker-chosen physical address.

The kernel-internal XPT path already knows this is unsafe — cam_xpt.c:1133 rejects CAM_DATA_PHYS for XPT_DEV_MATCH. The pass driver does not.

Two related defects sit on the same function:

1. No cdb_len clamp. For inline CDBs (cdb_bytes[IOCDBLEN], cam_ccb.h:587, IOCDBLEN = CAM_MAX_CDBLEN = 16, cam.h:53), a cdb_len of 255 makes the SIM read 255 bytes from the 16-byte array, over-reading adjacent csio/union ccb fields including kernel pointers (msg_ptr, data_ptr). The same class of pointer-vs-array confusion affects CAM_CDB_POINTER, CAM_SENSE_PTR, CAM_SENSE_PHYS, CAM_CDB_PHYS — none of which the pass driver inspects.

2. No privilege-boundary flag rejection. CAM_DATA_PHYS, CAM_CDB_PHYS, CAM_SENSE_PHYS are kernel-internal flags (set by kernel-allocated CCBs whose buffers the kernel already DMA-mapped). They have no legitimate meaning in a user-supplied CCB. Their presence is therefore always a request to bypass cam_periph_mapmem — and should be rejected.

Reproduction

$ ssh dfbsd-maxx 'cd poc/DF-1088 && ./df1088_trigger'      # as maxx (uid 1001)
[unpriv] open /dev/pass0: Permission denied (errno=13)
[unpriv] pass0 access denied at devfs (mode 0600) -- DF-1088 trigger is privilege-gated
[unpriv] re-run as root to exercise the CCB-shape signature via CAMIOCOMMAND

# as root (the only context that can open the device)
$ ./dfbsd-qemu/vm.sh run_root '/root/df1088_trigger'
[unpriv] open /dev/pass0: SUCCEEDED (fd=3) -- unexpected
[root] CAMIOCOMMAND CAM_DATA_PHYS|cdb_len=255: rc=0 errno=0 (Undefined error: 0)
[root] BUG: kernel forwarded attacker physical pointer to SIM without rejection (DF-1088 present)

The rc=0 (CCB forwarded) is the bug signature. The PoC was run three times — all three returned rc=0 with no rejection.

Fix

fix.diff (git-apply-able) adds two guards to passsendccb immediately after xpt_merge_ccb:

1. Reject any user CCB carrying CAM_DATA_PHYS | CAM_CDB_PHYS | CAM_SENSE_PHYS | CAM_CDB_POINTER | CAM_SENSE_PTR (all kernel-internal flags) with EINVAL.
2. For XPT_SCSI_IO/XPT_CONT_TARGET_IO, reject csio.cdb_len > IOCDBLEN.

The pre-existing CAM_DATA_PHYS == 0 test on the cam_periph_mapmem gate is now dead (we rejected the flag above) and is removed for clarity.

This mirrors the kernel-internal XPT pattern at cam_xpt.c:1133 and the upstream FreeBSD fix that adds similar flag rejections to its passsendccb.

Hardware / guest notes

• /dev/pass0 is present on the audit guest (attached to QEMU DVD-ROM via atapci0/cd0). No special hardware required to demonstrate the CCB flag-shape bug — passsendccb is reached for any open of the device.
• The DMA-to-arbitrary-physical-memory impact chain requires (a) an attacker-chosen physical data_ptr AND (b) a SCSI target that completes the I/O. (b) is present in the guest (the DVD-ROM), but the bug's real-world value is in a jail/securelevel context where a privileged capability is grantable and the device is exposed. The trigger PoC stops short of completing an actual DMA to a chosen physical address (no IOMMU bypass demonstration), but proves the kernel forwards the malicious CCB — which is the precise claim of the finding.