# DF-1112 — Stack buffer overflow in smbus_acpi_space_handler (GSBUS)

## Claim
`smbus_acpi_space_handler()` at `sys/bus/smbus/smbacpi/smbacpi.c:137` declares
`char buf[32]` for all GSBUS (ACPI GenericSerialBus) protocol transfers.

ACPICA allocates 257-byte buffers for `ATTRIB_BLOCK(0x0A)` and
`ATTRIB_BYTES(0x0B)` transfers (2-byte header + `ACPI_MAX_GSBUS_DATA_SIZE`
of 255 data bytes) — see `contrib/dev/acpica/source/components/events/evhandler.c`
and `evxface.c`. Three overflow paths exist:

1. **BLOCK WRITE** at smbacpi.c:208: `memcpy(buf, gsb->data, gsb->len)`
   with `gsb->len` up to 255 → up to **223-byte stack overflow**.
2. **BYTES WRITE** at smbacpi.c:223: `memcpy(buf, gsb->data, info->AccessLength)`
   with `info->AccessLength` up to 255 → same magnitude.
3. **BYTES READ** at smbacpi.c:217-219: `SMBUS_TRANS(..., buf, info->AccessLength, ...)`
   with `info->AccessLength` up to 255. The `ig4_iic.c` `smb_transaction`
   NOCNT branch writes `rcount` bytes into `rbuf` → same overflow magnitude.

BLOCK READ (smbacpi.c:199-206) is NOT affected — `count` is initialised to
32 (line 200) and `ig4_iic.c` caps via its `rcount > last` check.

The attacker controls the ACPI AML: malicious firmware, a root DSDT override
(`acpi_dsdt_load`), or a malicious hypervisor guest ACPI.

## Reproducibility on this guest
The audit guest's firmware (BOCHS BXPC) does not ship any GSBUS OpRegion in
its DSDT (`ACPI: DSDT 0x00000000BFFE0040 001AF8` — 0x1AF8 bytes, only
standard devices). `smbus_acpi_space_handler` is registered only if a
`smbus` device attaches under an ACPI-enumerated I2C controller with a GSBUS
opregion declaration; on this guest there is none, so the handler is never
invoked. Verified:

```
$ dmesg | grep -iE 'smbus|ig4|smbacpi'
(empty)
```

The bug is **latent** — confirmed by source trace. A realistic runtime
trigger would require either malicious firmware, a malicious hypervisor
controlling guest ACPI, or `root` triggering `acpi_dsdt_load` with a crafted
DSDT override. None of those is an unprivileged attack surface on this
guest.

## Fix
`fix.diff`: size `buf[]` to match the maximum GSBUS data size
(`ACPI_MAX_GSBUS_DATA_SIZE + 1 = 256`) so the buffer can hold any ACPICA
buffer without overflow.