DF-2265 verification pack — sasetparams ENODEV ccomp leak

Bug: sys/bus/cam/scsi/scsi_sa.c:2938-2941 — the compression- unsupported ENODEV exit frees mode_buffer and releases the ccb but never frees ccomp (allocated at :2757), leaking one sa_comp_t (16 bytes, M_SCSISA) per failed MTCOMP ioctl on drives reporting the DATA COMPRESSION page without the DCC bit.

Rig

Same harness kernel as DF-2263 (see ../DF-2263/README.md); the REAL sasetparams() and sagetparams() run against a fake transport (cam_periph_runccb interposed) that answers MODE SENSE(6) with a DCP page lacking DCC — the drive class the in-tree comment anticipates. Trigger equals saioctl(MTIOCTOP, MTCOMP) at :1266. Leak measured via in-kernel sums of M_SCSISA->ks_use[cpu].{memuse,calls}.

Build

./build.sh      # or reuse the kernel built from ../DF-2263

Run

vm.sh run_root 'sysctl debug.df226x.t2265=1000'
vm.sh run_root 'dmesg | grep DFH2265'

Expected

Unpatched: memuse grew by 16000 bytes = 1000 x sizeof(sa_comp_t) (16) after 1000 ENODEV returns (3 allocation calls per iteration, one object never freed). Patched (fix.diff adds kfree(ccomp, M_SCSISA); on the ENODEV path): memuse grew by 0 bytes.

Artifacts: VERDICT.md, df_pre.c, df_post.c, gen.sh, build.sh, quick.sh, run_unfixed.dmesg, run_fixed.dmesg, env.txt (in ../DF-2263), fix.diff.

DF-2265 — sasetparams ENODEV path leaks the ccomp allocation (M_SCSISA)

File: sys/bus/cam/scsi/scsi_sa.c Claim under verification: sasetparams() allocates ccomp (:2757 ccomp = kmalloc(sizeof(sa_comp_t), M_SCSISA, M_INTWAIT)), fills it via sagetparams() with the drive's compression page, and on the "device does not support compression" path (:2924-2941) frees only mode_buffer and releases the ccb:

if (params_to_set == SA_PARAM_NONE) {
        kfree(mode_buffer, M_SCSISA);
        xpt_release_ccb(ccb);
        return (ENODEV);          /* <-- ccomp leaked */
}

ccomp is freed on every OTHER exit (:2772 error, :3031 tail) but not here: 16 bytes of M_SCSISA per failed call, unbounded over ioctl retries.

Rig

Same kernel-compiled harness (verbatim sasetparams + sagetparams). The only fabricated element is the transport: cam_periph_runccb() is interposed by a fake transport that answers MODE SENSE(6) the way a real drive does when it returns the DATA COMPRESSION page (0x0f) WITHOUT the DCC ("compression capable", 0x40) bit — precisely the class of drive the in-tree comment at :2914-2922 anticipates ("Compression does not appear to be supported- at least via the DATA COMPRESSION page..."). Everything else — the two kmallocs, sagetparams' page parsing, the mode_buffer setup, the compression-page switch — is the real code. The trigger is exactly what saioctl(MTIOCTOP, MTCOMP) issues at :1266: sasetparams(periph, SA_PARAM_COMPRESSION, 0, 0, calg, 0).

Measurement: in-kernel sum of M_SCSISA->ks_use[cpu].{memuse,calls} across all CPUs before/after N=1000 iterations.

Results

UNPATCHED (run_unfixed.dmesg):

DFH2265: M_SCSISA before: memuse=0 calls=0, sizeof(sa_comp_t)=16, iterations=1000
DFH2265: M_SCSISA after: memuse=16000 calls=3000; returns: ENODEV=1000 other=0
DFH2265: *** LEAK: memuse grew by 16000 bytes = 1000 x sizeof(sa_comp_t) (16);
         allocation calls grew by 3000 (expect 3 per call: ccomp+mode_buffer+
         sagetparams buffer; ccomp is the one never freed on the ENODEV path)

Exactly one sa_comp_t (16 bytes) leaked per ENODEV return; the other two per-call allocations (mode_buffer, sagetparams' mode_buffer) are freed. Unbounded: a retry loop or script around mt comp on on such a drive grows M_SCSISA without bound (16 B/call; a 10 kHz ioctl loop leaks ~576 KB/hour; kernel memory never returned).

PATCHED (run_fixed.dmesg, fix2265.diff = add kfree(ccomp, M_SCSISA); before the ENODEV return):

DFH2265: M_SCSISA before: memuse=0 calls=0, sizeof(sa_comp_t)=16, iterations=1000
DFH2265: M_SCSISA after: memuse=0 calls=3000; returns: ENODEV=1000 other=0
DFH2265: *** LEAK: memuse grew by 0 bytes = 0 x sizeof(sa_comp_t) (16); ...

A/B clean: identical behavior (1000 ENODEVs, same 3000 allocations), zero net growth.

Reachability / severity honesty

Requires issuing MTIOCTOP/MTCOMP against a tape drive whose compression mode page reports no DCC capability — a privileged ioctl on the tape device node (root/operator). Slow, privileged-reach kernel memory leak: Info severity, exactly as filed. No privesc, no corruption.

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.