DF-1578 — hptrr INQUIRY/READ_CAPACITY/SERVICE_ACTION_IN heap OOB write

At a glance

The bug, in one sentence

hpt_scsi_io() writes fixed offsets into ccb->csio.data_ptr (INQUIRY: 0..35, READ_CAPACITY: 0..7, SERVICE_ACTION_IN: 0..11) without checking ccb->csio.dxfer_len; a CCB with dxfer_len=0 (root-only via /dev/passN) corrupts memory past the data buffer.

Reproduce on this guest

Cannot run. hptrr is in X86_64_GENERIC but no HighPoint RR17xx PCI RAID controller is present, so the driver never attaches and no virtual disk is registered with CAM. Additionally the only user-reachable path to a hostile dxfer_len is /dev/passN (mode 0600 root). See VERDICT.md for the full reachability analysis and fix_build.log for the patched-module rebuild.

Apply the fix

cd /usr/src
patch -p1 < findings/poc/DF-1578/fix.diff
# In sys/dev/raid/hptrr:
make SYSDIR=/usr/src/sys      # rebuild hptrr.ko

Files in this folder

DF-1578 — Heap OOB write in hptrr INQUIRY/READ_CAPACITY/SERVICE_ACTION_IN

Verdict

NOT REPRODUCED ON THIS GUEST — the bug is real in source (line-by-line confirmed), and hptrr is in X86_64_GENERIC, but no HighPoint RR17xx/22xx/23xx/25xx RAID controller is present in the QEMU guest so the driver never attaches and hpt_scsi_io is never called. Even with hardware, the only path to delivering an attacker-controlled dxfer_len CCB is /dev/passN, which is mode 0600 root — i.e. this is a root→kernel hardening gap, not an unprivileged→root escalation. Fix authored, applies cleanly, compiles cleanly with -Werror.

The bug (confirmed in source)

sys/dev/raid/hptrr/hptrr_osm_bsd.c, function hpt_scsi_io (lines 535-741), cases INQUIRY / READ_CAPACITY / SERVICE_ACTION_IN:

INQUIRY (lines 579-601)

case INQUIRY:
    {
        PINQUIRYDATA inquiryData;
        memset(ccb->csio.data_ptr, 0, ccb->csio.dxfer_len);   /* line 582 */
        inquiryData = (PINQUIRYDATA)ccb->csio.data_ptr;
        inquiryData->AdditionalLength = 31;          /* byte 4 */
        inquiryData->CommandQueue = 1;               /* byte 7 */
        memcpy(&inquiryData->VendorId, "HPT     ", 8);            /* bytes 8-15 */
        memcpy(&inquiryData->ProductId, "DISK 0_0        ", 16);  /* bytes 16-31 */
        ...
        memcpy(&inquiryData->ProductRevisionLevel, "4.00", 4);    /* bytes 32-35 */

• PINQUIRYDATA is struct _INQUIRYDATA (os_bsd.h:82-106): offset 4 = AdditionalLength; offset 7 = CommandQueue bit; bytes 8-15 = VendorId[8]; bytes 16-31 = ProductId[16]; bytes 32-35 = ProductRevisionLevel[4].
• The handler writes to fixed offsets 0..35 (36 bytes minimum) without ever checking ccb->csio.dxfer_len.
• If dxfer_len is 0 (or smaller than the highest offset written), every write past data_ptr + dxfer_len corrupts adjacent kernel memory.

READ_CAPACITY (lines 603-624)

• Writes rbuf[0]..rbuf[7] (8 bytes), no dxfer_len check.

SERVICE_ACTION_IN (lines 626-646)

• Writes rbuf[0]..rbuf[11] (12 bytes), no dxfer_len check.

Reachability on this guest

• hptrr is in X86_64_GENERIC — statically compiled into the default kernel.
• But pciconf -l shows no RAID controller matching hptrr's PCI IDs; dmesg shows only hpt27xx: no controller detected. (the sibling driver; hptrr itself never printed an attach message).
• Therefore hpt_scsi_io is never called at runtime — no VDEV was registered with the CAM layer.
• Even on a host with hptrr hardware attached, the only way for an attacker to deliver a CCB with a hostile dxfer_len is via the CAM pass-through layer: /dev/passN. On this guest /dev/pass0 is crw------- 1 root operator — mode 0600 root. An unprivileged user cannot open it.

Why the kernel-initiated probe path does not trigger the bug

When the kernel itself probes a newly-attached disk, the peripheral drivers (da, cd, pass) issue INQUIRY etc. with proper allocation lengths (dxfer_len >= 96 for INQUIRY, etc.). The bug requires a maliciously small dxfer_len, which only an explicit user-issued CCB via /dev/passN (root-only) can supply.

Realistic threat model

• root → kernel: a root user with hptrr hardware (or with the driver attached to a crafted virtual RAID) can ioctl(/dev/passN) to send a CCB with dxfer_len=0 against the hptrr SIM, causing the OOB write. This is a root→kernel hardening gap — root can already kldload/write/devfs-clone its way to ring 0, so the practical security impact is low.
• Unprivileged user: no path identified. The standard SCSI disk peripheral (da) does not propagate user-controlled dxfer_len values down to the SIM; only the pass-through (pass) peripheral does, and that requires root.
• Same code shape exists in the sibling hpt27xx driver — note the in-guest dmesg shows hpt27xx was probed and found no controller (no separate finding exists for hpt27xx's identical code yet).

Exploit chain

Not applicable. The primitive (a fixed-pattern OOB write up to 36 bytes past a caller-supplied buffer) is only reachable from root via /dev/passN, which is a valid hard blocker (the write is reachable only from an already-root context). No unprivileged path exists; therefore no escalation chain is possible. Documented as a root→kernel hardening gap with a verified fix.

The fix

fix.diff — add a dxfer_len minimum-size check at the top of each of the three affected cases, returning CAM_REQ_ABORTED if the caller did not supply enough buffer for the response. Minimal, targeted, three small hunks.

 case INQUIRY:
     {
         PINQUIRYDATA inquiryData;
+        if (ccb->csio.dxfer_len < 36) {
+            ccb->ccb_h.status = CAM_REQ_ABORTED;
+            break;
+        }
         memset(ccb->csio.data_ptr, 0, ccb->csio.dxfer_len);
         ...

 case READ_CAPACITY:
     ...
+    if (ccb->csio.dxfer_len < 8) {
+        ccb->ccb_h.status = CAM_REQ_ABORTED;
+        break;
+    }

 case SERVICE_ACTION_IN:
     ...
+    if (ccb->csio.dxfer_len < 12) {
+        ccb->ccb_h.status = CAM_REQ_ABORTED;
+        break;
+    }

PoC changes

No userspace PoC is included because (a) the driver is not attached on this guest and (b) the trigger requires /dev/passN which is root-only. A PoC would be a small camcontrol/pass ioctl program run by root against an attached hptrr virtual disk — but the security value of root→kernel primitives is marginal.

Reproduce

Not runnable on this guest (no hptrr hardware). See fix_build.log for the full patched-module rebuild.