DF-5507 PoC — /dev/smb SMB_BREAD hands amdsmb_bread an uninitialized kernel-stack count: feature-dead for 224/256 stack bytes, and for garbage in [1,32) it returns a count larger than the bytes it stored → kernel-stack disclosure via smbioctl copyout

Root cause (amdsmb side of the DF-5458 twin)

amdsmb_bread (sys/bus/smbus/amdsmb/amdsmb.c:517-547) implements the smbus(4) in/out-count contract: the caller passes its requested capacity in *count; on success the driver stores min(hw_len, *count) bytes into buf and sets *count to the hardware byte count len (amdsmb.c:533-539):

amdsmb_ec_read(sc, SMB_BCNT, &len);
for (i = 0; i < len; i++) {
        amdsmb_ec_read(sc, SMB_DATA + i, &data);
        if (i < *count)                    /* stores only up to capacity */
                buf[i] = data;
}
*count = len;                              /* reports hw len, not stored */

The only in-kernel caller, /dev/smb smbioctl (sys/dev/smbus/smb/smb.c:318-330), passes a kernel-stack byte that is never initialized:

u_char bcount;                              /* smb.c:317 */
...
case SMB_BREAD:
        ...
        error = smbus_bread(bus, s->slave, s->cmd, &bcount, buf);  /* :323 */
        ...
        if (s->rcount > bcount) s->rcount = bcount;                /* :327 */
        error = copyout(buf, s->rbuf, s->rcount);                  /* :329 */

buf there is char buf[SMB_MAXBLOCKSIZE=1024] on the smbioctl kernel stack (smb.c:211). Two consequences, both exercised through the real production amdsmb_bread:

1. EINVAL gate: garbage stack byte 0 or 33..255 → amdsmb_bread rejects with SMB_EINVAL (amdsmb.c:524-525) — SMB_BREAD on amdsmb is dead for 224/256 possible stack bytes (deterministic failure; this is the exact twin of ichsmb's DF-5458, filed there against the same smb.c defect).
2. Kernel-stack disclosure: garbage byte g in [1,32) with a perfectly healthy slave delivering len=32 → the driver stores only g bytes but reports *count = 32; smbioctl then copyouts min(rcount<=1024, 32) bytes from buf, of which 32 - g were never written — up to 31 uninitialized kernel-stack bytes per call with a well-behaved slave (no DF-1091 hostility needed). Combined with the known slave-controlled count (DF-1091, len up to 255) the disclosure grows to min(1024, len) - g ≥ 254 bytes.

Additionally amdsmb_bwrite transmits whatever garbage g in [1,32] it receives as the on-wire byte count (SMB_BCNT gets g — T3w), i.e. a malformed-length Block Write, again the DF-5458 pattern.

Reachability: /dev/smbN (root on stock installs) → ioctl SMB_BREAD / SMB_BWRITE. Hardware-gated (AMD-8111) — evidence via the production-code KLD harness (see DF-5506 pack; amdsmb.c asserted byte-identical to /usr/src).

Observed (run.log, T3/T3w — real production amdsmb_bread/bwrite)

g=  0 -> rc=256 SMB_EINVAL        g=  1 -> rc=0 count=32 stale=31
g= 33 -> rc=256 SMB_EINVAL        g=  5 -> rc=0 count=32 stale=27
g=255 -> rc=256 SMB_EINVAL        g= 31 -> rc=0 count=32 stale= 1
                                  g= 32 -> rc=0 count=32 stale= 0
bwrite: g in [1,32] -> transmitted_BCNT = g (garbage length on the wire)

Observed (run_fixed.log — fix.diff applied to the harness copy)

fix.diff clamps the driver out-count to what it actually stored:

g=1 -> count=1 stale=0    g=5 -> count=5 stale=0
g=31 -> count=31 stale=0  g=32 -> count=32 stale=0

The driver-side disclosure is gone for BOTH input vectors (garbage count and the known DF-1091 hostile len: T4 fixed stops at register 0x24, count=32). The EINVAL gate for g∈{0,33..255} remains by design until smb.c initializes bcount (bcount = s->rcount; before smb.c:323) — that one-line smb.c change is the complete upstream fix for the uninitialized-input side and is recommended alongside.

Build & run

Same rig as DF-5506: guest# cd /root/amdh && sh build.sh && sh run.sh (tests T3/T3w are this finding; T1/T2/T2b belong to DF-5506).

DF-5507 VERDICT — REPRODUCED (mechanism, through the production amdsmb_bread); driver-side fix validated; smb.c input-init remains upstream's one-liner

Bottom line

The /dev/smb layer passes an uninitialized kernel-stack byte as amdsmb_bread's in/out count (sys/dev/smbus/smb/smb.c:317,323 — the same defect twin-filed for ichsmb as DF-5458). amdsmb's handling of that count (sys/bus/smbus/amdsmb/amdsmb.c:524-539) turns it into two user-visible defects, both demonstrated by executing the unmodified production source in-kernel against the AMD-8111 EC register emulator:

1. For 224/256 possible garbage values (g=0, g>32) amdsmb_bread returns SMB_EINVAL — SMB_BREAD is deterministically broken on amdsmb exactly as DF-5458 showed for ichsmb (T3).
2. For g in [1,32) with a healthy slave (len=32) the driver stores only g bytes into the caller's buffer but sets *count = len (amdsmb.c: 539); smbioctl then copyouts min(rcount≤1024, len) bytes from its 1024-byte kernel-stack buffer (smb.c:327-329), disclosing len - g never-written stack bytes — up to 31 per call with a well-behaved slave, and ≥254 when combined with the known slave-controlled count (DF-1091's len≤255). T3 measures the driver-side arithmetic exactly: g=1→31 stale, g=5→27, g=31→1, g=32→0.
3. amdsmb_bwrite puts the garbage g on the wire as the block length (SMB_BCNT←g, T3w) — malformed Block Writes.

Impact ceiling: kernel-stack info disclosure to a /dev/smb opener (root/operator-gated; the device is 0600 root on stock DragonFly) — Medium like the ichsmb sibling DF-5457/DF-5458 pricing. Not a memory-corruption primitive: the OOB is read-side disclosure only; the kernel-memory WRITE in bread is bounded by the original *count ≤ 32 (amdsmb.c:536-537).

Distinction from the excluded known findings

DF-1091/DF-2330 (excluded from this pass-2) cover the slave-controlled hw byte count: OOB MMIO register reads past the 32-byte bank and the inflated out-param. This finding's input vector is the caller-side uninitialized kernel-stack count (smb.c:317/323): it breaks SMB_BREAD independently of any slave misbehavior and creates the stale-stack-copyout even when the slave returns a perfectly legal len ≤ 32. T4 in the shared run corroborates the known DF-1091 behavior (register reads to 0xFF with 8-bit address wraparound; count=255) and is explicitly labeled as corroboration, not a new finding.

Fix validation

fix.diff (shared with DF-5506's pack; amdsmb.c bread hunk) clamps len to 32 (DF-1091 family hardening) and then to the caller's capacity so the out-count always equals the bytes stored. Fixed-build T3: g=1→ count=1 stale=0, g=5→count=5 stale=0, g=31→count=31 stale=0 — the driver can no longer report more bytes than it wrote; the disclosure sink is closed for both input vectors (hostile len included: fixed T4 stops at register 0x24, returns count=32). The EINVAL gate for g∈{0, 33..255} is correct driver behavior for an invalid count; eliminating it requires the smb.c fix (bcount = s->rcount; before smb.c:323), which also un-breaks SMB_BREAD on both ichsmb and amdsmb.

Reproduction honesty

Same rig and caveats as DF-5506: AMD-8111 has no QEMU model; the production amdsmb.c (byte-identical to /usr/src, build.log:1) executes in-kernel against the EC register emulator. The g-truth-table is deterministic driver logic; the only emulated element is what the hw BCNT/DATA registers contain (len=32 healthy-slave case). The smb.c epilogue arithmetic cited for the copyout length is source-verified (smb.c:211,317-330) and matches DF-5458's live ichsmb observation of the same layer.

Kernel references

sys/bus/smbus/amdsmb/amdsmb.c:517-547 (bread), :524-525 (EINVAL gate), :533-539 (stores min(len,*count), reports len), :497 (bwrite gate); sys/dev/smbus/smb/smb.c:211 (1024-byte stack buf), :317 (uninit bcount), :318-330 (SMB_BREAD epilogue), :305-316 (SMB_BWRITE).

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.