DF-3930 — mly: mly_cam_complete() INQUIRY rewrite writes past a short CAM data buffer (heap OOB write)

Build / Run (on hardware)

Needs an mly controller with a logical device and access to its pass(4) device (root, or operator where devfs grants it):

camcontrol cmd 3:0:0 -c "12 00 00 00 04 00" -d 4 # 4-byte INQUIRY data-in

or equivalently a pass(4) XPT_SCSI_IO CCB with cdb_len=6, cdb[0]=INQUIRY (0x12), dxfer_len=4, CAM_DIR_IN targeting the logical volume. sc->mly_btl[bus][target].mb_flags & MLY_BTL_LOGICAL must be set (it is, for mly virtual targets).

Expected result

mly_cam_complete() (status OK, cmd==INQUIRY) unconditionally rewrites vendor/product/revision at data_ptr+8..+36 (padstr calls, mly.c:2343-2345) regardless of dxfer_len. With a 4-byte buffer this writes ~32 bytes of device-descriptive text past a 4-byte kernel allocation — adjacent heap corruption (mchunk metadata / neighbouring object headers).

No mly hardware in the audit guest → not runtime-reproduced; source-certain. See VERDICT.md.

DF-3930 verdict narrative

Reproduced?

No (hardware-gated: guest has no mly controller). Source-level certainty: certain.

Root cause chain (path:line)

mly.c:2331-2346 (mly_cam_complete, SCSI_STATUS_OK path): c if (sc->mly_btl[bus][target].mb_flags & MLY_BTL_LOGICAL) { cmd = <cdb[0]>; /* 0x12 == INQUIRY */ if (cmd == INQUIRY) { btl = &sc->mly_btl[bus][target]; inq = (struct scsi_inquiry_data *)csio->data_ptr; /* :2318 */ padstr(inq->vendor, ..., 8); /* writes data_ptr[8..16) */ padstr(inq->product, ..., 16); /* writes data_ptr[16..32) */ padstr(inq->revision, "MYLX", 4); /* writes data_ptr[32..36) */ } }

csio->data_ptr / dxfer_len come straight from the CAM client. For a normal probe INQUIRY dxfer_len is 36 so the rewrite fits. But pass(4) forwards user-chosen CCBs: a 6-byte INQUIRY CDB with a short data-in buffer (e.g. 4 bytes — the allocation pass makes for the transfer) reaches the driver verbatim; the controller truncates its reply, status comes back OK, and padstr then writes at offsets 8..36 of a 4-byte kmalloc buffer — an out-of-bounds heap write of up to 32 bytes past the allocation.

Layout facts: struct scsi_inquiry_data has vendor at offset 8, product at 16, revision at 32 (scsi_all.h); padstr (mlyvar.h:362-372) writes exactly len bytes.

The written content is static text (mly_tables.h strings, "MYLX") and space-fill — not attacker bytes, but the length/position are attacker-chosen (dxfer_len 0..35 selects how far past the end writes begin), and the clobbered neighbours are kernel heap metadata/objects. On this guest's slab allocator (a 4-byte request rounds to an 8-byte chunk) the write runs over the following chunk's header.

Threat model

Local privileged-ish user (pass device; typically root, operator where granted) on a machine with an mly logical volume. Requires the volume to report OK status for the short inquiry — it does, the card merely truncates.

Impact

Bounded (~32B) kernel heap OOB write with fixed content at a length-controlled offset — heap metadata corruption, panic most likely; exploitability limited by the static content but nonzero (chunk-header clobbering).

Distinct from knowns: DF-1289 is the sense_data overflow in the same function (mly.c:2356-2358); this is the INQUIRY-rewrite path (mly.c:2341-2346).

Fix

Gate the rewrite on csio->dxfer_len >= 36 — fix.diff.

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.