Summary

In amdpm_bread, after the SMBus block-read transaction completes, the slave-supplied count byte is read from HSTDATA into local len (line 613) and blindly written back to the caller's *count at line 622. The internal buffer-write loop (lines 616-621) is correctly bounded by the original *count (validated ≤ 32 at line 592) via if (i < *count), but the returned *count = len can exceed both the original request and the 32-byte hardware FIFO. Callers that trust the returned count — smb(4) copying from an uninitialized stack buffer, or IPMI SSIF bcopy-ing from a 32-byte stack buffer — read past valid data, leaking kernel stack memory or causing an in-kernel OOB read.

Root cause

At amdpm.c:613:

len = AMDPM_SMBINW(sc, AMDSMB_HSTDATA);

This reads the count byte the SMBus slave supplied during the block-read transaction (the AMD 8111 SMBus controller stores the slave's count in HSTDATA). The FIFO write loop at lines 616-621 correctly guards buf[i] = data with if (i < *count) using the original caller-supplied *count (still intact, validated ≤ 32 at line 592):

for (i = 0; i < len; i++) {
    data = AMDPM_SMBINB(sc, AMDSMB_HSTDFIFO);
    if (i < *count)
        buf[i] = data;
    DELAY(2);
}
*count = len;       /* <-- line 622: overwrites caller count with raw HW value */

Since HSTDATA is a u_short and len is a u_char, len can be 0–255. The AMD 8111 FIFO is only 32 bytes, so any len > 32 means: (a) the loop reads stale/garbage from HSTDFIFO beyond 32 entries (harmless register reads), (b) buf was only populated up to min(original_count, 32) bytes, but (c) the caller is told len bytes are valid.

The sibling driver sys/bus/smbus/amdsmb/amdsmb.c:539 has the identical defect, and ichsmb (sys/bus/smbus/ichsmb/ichsmb.c:441) has the same shape (*count = sc->block_count).

Threat model & preconditions

• Attacker position: root opening /dev/smb* (mode 0600, smb.c:136), OR an in-kernel consumer (IPMI-over-SSIF) talking to a malicious/compromised BMC.
• Privileges gained or impact:
• Primary userspace path: kernel-stack info leak. An attacker with root privilege opens /dev/smb0 and issues SMB_BREAD with rcount=SMB_MAXBLOCKSIZE (1024). If the addressed slave returns a count byte > 32 (a malicious peripheral, buggy EEPROM, or crafted I2C device), amdpm_bread sets bcount to that value. smb.c:327-329 then does s->rcount = min(s->rcount, bcount); copyout(buf, s->rbuf, s->rcount) from an uninitialized char buf[1024] (smb.c:211). Only min(original_bcount, 32) bytes were written; the remainder is uninitialized kernel stack leaked to userspace — can disclose kernel pointers (KASLR bypass), stack canaries, or adjacent stack data.
• In-kernel path: IPMI SSIF (ipmi_ssif.c:73 declares u_char ssif_buf[32], passes count=32 at line 184) does bcopy(&ssif_buf[3], req->ir_reply, min(req->ir_replybuflen, count-3)) at line 241 — if amdpm_bread returns count > 32, this reads past the 32-byte ssif_buf on the IPMI thread's stack.
• Required config or capabilities: AMD 8111 SMBus controller (this driver); for the IPMI path, additionally IPMI-over-SSIF with a compromised/malicious BMC. Default DFly has no devfs rule granting non-root access to /dev/smb*.
• Reachability: SMBus block-read transaction to a slave that returns a count byte larger than its actual payload.

Proof of concept

PoC source: findings/poc/DF-1833/amdpm_leak.c

Build & run

cc amdpm_leak.c -o amdpm_leak
# Slave at addr 0x50 must return a block count > 32 (a malicious peripheral
# or crafted I2C device). Root required for /dev/smb0.
sudo ./amdpm_leak /dev/smb0 0x50

Expected output

returned rcount=<n>      # n > 32 when the slave lies
<bytes beyond offset min(orig,32) are leaked kernel stack, non-zero / non-pattern>

For the IPMI-SSIF OOB path no userspace PoC exists; trigger is a BMC that responds to SSIF READ_START with a block-count byte > 32 while the SMBus controller is amdpm. ipmi_ssif.c:241 bcopy reads past ssif_buf[32].

Impact

Low-severity kernel-stack info leak reachable via root + a malicious/crafted SMBus peripheral, or via a compromised BMC in IPMI-SSIF configurations. Default DFly does not grant non-root /dev/smb* access. The leak can disclose kernel pointers and stack canaries but is gated behind root and a cooperating slave.

Recommended fix

Clamp the slave-supplied count to the original *count (already validated ≤ 32 at line 592) before using it for both the loop bound and the returned count. This ensures the caller never sees a count larger than the buffer it offered and the bytes actually written.

--- a/sys/dev/powermng/amdpm/amdpm.c
+++ b/sys/dev/powermng/amdpm/amdpm.c
@@ -610,11 +610,16 @@ amdpm_bread(device_t dev, u_char slave, char cmd, u_char *count, char *buf)
        goto error;

    len = AMDPM_SMBINW(sc, AMDSMB_HSTDATA);
+   /*
+    * The slave supplies the count byte; clamp it to the caller's
+    * original request (already validated <= 32) so *count never
+    * exceeds the bytes actually written into buf.
+    */
+   if (len > *count)
+       len = *count;

    /* Read the 32-byte internal buffer */
    for (i = 0; i < len; i++) {
        data = AMDPM_SMBINB(sc, AMDSMB_HSTDFIFO);
-       if (i < *count)
-           buf[i] = data;
+       buf[i] = data;
        DELAY(2);
    }
    *count = len;

The same fix should be applied to: - sys/bus/smbus/amdsmb/amdsmb.c:533-539 (identical unbounded *count = len) - sys/bus/smbus/ichsmb/ichsmb.c:441 (same shape *count = sc->block_count)

References

• Sibling defects: amdsmb.c:539, ichsmb.c:441.
• Caller info-leak path: smb.c:211, 327-329 (uninitialized char buf[1024]).
• Caller OOB read path: ipmi_ssif.c:73, 184, 241 (bcopy from 32-byte ssif_buf).

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).