DF-5284 — sasetparams transmits uninitialized kernel heap in MODE SELECT

sys/bus/cam/scsi/scsi_sa.c — CAM SCSI sequential-access (tape) driver.

Root cause

sasetparams() allocates the compression-page scratch ccomp with kmalloc(sizeof(sa_comp_t), M_SCSISA, M_INTWAIT) — no M_ZERO (scsi_sa.c:2757) — then fills it via sagetparams(..., ccomp).

But sagetparams() silently drops SA_PARAM_COMPRESSION from its local params_to_get when SA_QUIRK_NOCOMP is set (scsi_sa.c:2569-2572) and never writes *tcs. The quirk is set inside that very call when the compression-page EINVAL fallback exhausts (scsi_sa.c:2601-2607) — i.e. after the caller (the MTCOMP ioctl, which had checked the quirk before it was set) already committed to setting compression.

sasetparams() then:

• bcopy(ccomp, cpage, sizeof(sa_comp_t)) — copies 16 bytes of uninitialized kernel heap into the MODE SELECT buffer (scsi_sa.c:2796, error path again at 3009),
• branches on the uninitialized ccomp->hdr.pagecode byte (scsi_sa.c:2863) — a kernel-control-flow decision driven by stale heap,
• transmits the buffer to the device via scsi_mode_select() (scsi_sa.c:2954) whenever the stale pagecode byte matches SA_DEVICE_CONFIGURATION_PAGE (0x10) or SA_DATA_COMPRESSION_PAGE (0x0f) — on production (non-INVARIANTS) kernels that byte is heap groomable.

Build (guest, root)

cd /root/df5284
touch opt_cam.h && make
cc -O -o poc_comp poc_comp.c

Run

sh run.sh

1. kldload evilsa.ko — fake T_SEQUENTIAL target attaches as sa0.
2. poc_comp /dev/nsa0 (pinned with usched :1): * opens the tape (mount with a valid compression page), * flips debug.evilsa.nocomp=1: MODE SENSE pages 0x0f/0x10 now fail with CAM_REQ_INVALID (→ EINVAL → the fallback that sets NOCOMP), * debug.evilsa.spray16=1: allocates 4096 x 16B chunks, stamps the kernel pointer &ev_lock at [8..15], and frees the chunks whose addresses end in 0x10/0x90 last, so the chunk returned by the next kmalloc(16) (= ccomp) has freelist-linkage byte0 = 0x10 — steering the uninitialized switch into the branch that transmits, * issues MTCOMP (algorithm 1).

Expected result

evilsa captures the 28-byte MODE SELECT and hexdumps payload[12..27]: the 16 uninitialized bytes. On a kernel without INVARIANTS these are the freelist linkage pointer (bytes 13..19) and the sprayed marker &ev_lock (bytes 20..27, byte 24 overwritten by the algorithm value):

[EVILSA] MODE SELECT #1 len 28 payload[12..27]:
[EVILSA]   10 00 f9 8a 00 f8 ff ff 00 00 00 01 c0 d5 60 82
[EVILSA]   MARKER HIT: payload[20..27] matches &ev_lock=0xffffffff8260d5c0 (byte 24 = calg)

(Example from the NOINVARIANTS baseline kernel; see run.log.)

Guest-kernel caveat

The stock audit kernel is built options INVARIANTS, which poisons bytes [0..7] of every non-M_ZERO kmalloc with (void *)-1. That makes the uninitialized pagecode deterministically 0x7F, so on that build the switch always falls into default → ENODEV and the page is never transmitted (run.inv-kernel.log: (sa0): device does not seem to support compression — the kernel branching on the uninitialized byte, plus probe16 hexdumps showing the marker sitting in ccomp). The transmit leg was verified on a same-source kernel without INVARIANTS (run.log), which is what production ships.

Fix

fix.diff: M_ZERO on the ccomp allocation (plus the DF-5285/DF-5286 guards). With the fix, the payload bytes are zero and the marker never appears.

DF-5284 VERDICT — reproduced (leak, kernel heap to device via MODE SELECT)

What was claimed

sasetparams() in sys/bus/cam/scsi/scsi_sa.c transmits 16 bytes of uninitialized kernel heap to the SCSI device inside a MODE SELECT command when the compression-page EINVAL fallback fires.

Reproduced? Yes — deterministically, first MTCOMP attempt, on a

same-source kernel built without INVARIANTS (what production ships).

Mechanism (all lines verified in-tree and on-guest)

1. MTCOMP ioctl passes the quirk gate (scsi_sa.c:1261 — neither SA_QUIRK_NOCOMP nor SA_FLAG_COMP_UNSUPP set yet).
2. sasetparams(SA_PARAM_COMPRESSION) kmallocs ccomp without M_ZERO (scsi_sa.c:2757) and immediately calls sagetparams() to fill it.
3. evilsa rejects MODE SENSE pages 0x0f and 0x10 with CAM_REQ_INVALID; saerror()→cam_periph_error() maps that to EINVAL, so sagetparams() walks its fallback (scsi_sa.c:2593-2607): page 0x0f → retry page 0x10 → retry again after setting SA_QUIRK_NOCOMP — and on that third pass (scsi_sa.c:2569-2572) it silently drops SA_PARAM_COMPRESSION and returns success without ever writing *tcs. ccomp still holds whatever was in the recycled heap chunk.
4. bcopy(ccomp, cpage, 16) copies the stale bytes into the MODE SELECT page (scsi_sa.c:2796), the driver branches on the stale ccomp->hdr.pagecode byte (scsi_sa.c:2863), and with pagecode 0x10 (heap-groomable — see below) issues the 28-byte MODE SELECT (scsi_sa.c:2954).

The groom (why it is deterministic, not luck)

On a non-INVARIANTS kernel a freed 16B slab chunk carries the freelist linkage in bytes[0..7] (kern_slaballoc.c:1584 chunk->c_Next = z->z_LChunks). evilsa's spray16 frees only chunks whose own addresses end in 0x10/0x90 last, so every chunk near the free-list head links to another 0x10/0x90-address chunk — the chunk handed to ccomp = kmalloc(16) deterministically has pagecode == 0x10 → the SA_DEVICE_CONFIGURATION_PAGE branch → MODE SELECT with the page. Verified 3/3 boots, attempt 0 each time (run.log, run.2.log, run.3.log, decode in dmesg.leak.txt).

Leaked bytes (per call, repeatable per fresh mount)

• bytes[13..19]: live kernel heap pointer (slab freelist linkage, 0xfffff8004f0bXXXX-class) — heap layout disclosure;
• bytes[20..27]: the remainder of the recycled chunk — in the PoC the sprayed marker &ev_lock (kernel .data address), proving arbitrary prior heap content crosses the trust boundary.

Why the stock audit guest masked the transmit leg

The audit guest's kernel is options INVARIANTS; slaballoc() then poisons bytes[0..7] of every non-M_ZERO kmalloc with (void *)-1 (kern_slaballoc.c:1153), forcing pagecode 0x7f → the switch takes default → ENODEV before transmitting. On that build the uninitialized-memory use is still directly observable: the console shows (sa0:evilsa0:0:0:0): device does not seem to support compression — the kernel branching on the uninitialized byte (run.inv-kernel.128loop.log), and probe16 hexdumps show the marker sitting in the exact chunk ccomp received. The transmit was then verified on the same-source X86_64_NOINV kernel.

Fix validation

fix.diff (shared with DF-5285/DF-5286) adds M_ZERO to the ccomp kmalloc. Same-source NOINV kernel rebuilt (fix_build.log), installed, rebooted; identical PoC re-run: 128 MTCOMP attempts, debug.evilsa.msel28 stays 0, no 28-byte MODE SELECT captured, no marker bytes anywhere (run.patched.log). Baseline on the identical unpatched kernel transmitted on attempt 0.

Rig notes (honesty)

• One rig bug during bring-up: int aidx[4096] on the sysctl handler's kernel stack → stack overflow → double fault; moved to .bss.
• The "MARKER HIT" kprintf verdict line in evilsa mis-flags despite the bytes matching (cosmetic rig bug, not investigated further); the hexdump lines are the evidence and are decoded in dmesg.leak.txt.
• The ENODEV attempts consume ccomp chunks without freeing — that is the already-known DF-2265 leak, not re-reported here.

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.