DF-4042 — Hostile SCSI target panics the kernel via MESSAGE REJECT of the driver's own MSG_ABORT/MSG_NOOP: amdsentmsg panic("Inconsistent msg buffer")

File: sys/dev/disk/amd/amd.c Severity: Medium | Class: CWE-670 Always-Incorrect Control Flow Implementation (kernel panic on hostile input) Status: hardware-gated — source-certain; runtime reproduction impossible on the audit guest (no Polaris GPU / no AMD53C974 HBA — see env.txt). Verdict: inconclusive, confidence certain.

Build & run (on the DragonFly guest)

./build.sh     # compiles the demonstrator (uses the guest's kernel headers)
./run.sh       # reproduces the exact index arithmetic / branch selection

Expected: the DF-4042 section of run.log shows the OOB offsets / panic-branch selection / fault. Full guest details in env.txt.

Fix validation

fix.diff applied (with all DF-4036..DF-4044 patches together) to a clean guest /usr/src copy; make nativekernel KERNCONF=X86_64_GENERIC completed with 0 errors under -Werror (see fix_build.log — amd.o recompiled). Sources restored to pristine afterwards (md5-verified).

DF-4042 VERDICT — Hostile SCSI target panics the kernel via MESSAGE REJECT of the driver's own MSG_ABORT/MSG_NOOP: amdsentmsg panic("Inconsistent msg buffer")

Bottom line

Source-certain kernel panic from device-fed message flow: after an unexpected reselection amd_Reselect queues msgout=[MSG_ABORT] (amd.c:1839-1840) and amd_MsgOutPhase1 substitutes [MSG_NOOP] when msgout_len==0 (amd.c:1745-1748); if the target then replies MESSAGE REJECT (any target may legally reject any optional message), amdparsemsg (amd.c:1246) -> amdhandlemsgreject (amd.c:1467) -> amdsentmsg walks msgout_buf and hits the terminal else panic("amdsentmsg: Inconsistent msg buffer") at amd.c:1435 because MSG_ABORT(0x06)/MSG_NOOP(0x08) are not in its recognized set (identify/REJECT/2-byte tag/EXT only). Verified by compiling the verbatim amdsentmsg copy on the guest and driving it with the two real driver states — both select the panic branch (run.log DF-4042). amd(4) is in the GENERIC kernel (X86_64_GENERIC:88); trigger requires a hostile/compromised SCSI target (or emulation), so runtime reproduction on this guest (no AMD53C974 HBA) is impossible -> inconclusive at runtime, source certain.

Exploit chain

hostile target: reselect an idle ID (driver queues ABORT) -> send MESSAGE REJECT byte in MSG IN -> amdhandlemsgreject -> amdsentmsg walk -> panic at amd.c:1435 (kernel DoS from interrupt context)

Why not reproduced on the guest

The audit guest has no AMD53c974-compatible SCSI HBA (env.txt); amd(4) is compiled into the GENERIC kernel but never attaches, so the hostile-target message flows cannot be exercised at runtime. The exact walks were compiled from the driver source (verbatim amdsentmsg copy / exact branch ladder / exact store) and driven with the real driver states (run.log); the fix is compile-validated (fix_build.log).

Negative results recorded alongside (pass-2 depth)

Kills proven in run.log: msgin_buf[6] per-byte walk max index 4 (bounded); SRB_array[msgin_buf[1]] 0..255 fits SRB_array[256] exactly; msgout shift bcopy fits msgout_buf[6]; amdtimeout/callout family is #if 0 dead code (no timeout-vs-intr race); EEPROM word walks fit eepromBuf[128] exactly; XPT_RESET_BUS ACBFlag race can only strand CCBs (hang, logged, not filed).

Fix

Replace the panic() with a bail-out break (treat as not found) — the buffer is driver-own, never worth dying over (fix.diff). Applied and compile-validated on the guest (fix_build.log); sys/ tree never modified by the audit.

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.