/*
 * DF-1112 — minimal proof of the smbus_acpi_space_handler buf[32] stack
 * overflow.
 *
 * The bug is in `smbus_acpi_space_handler` at smbacpi.c:137 onwards.
 * `char buf[32]` is used as the transfer buffer for every GSBUS protocol,
 * but ACPICA allocates 257-byte buffers (header + 255 data bytes) for
 * ATTRIB_BLOCK(0x0A) and ATTRIB_BYTES(0x0B).  Three overflow paths:
 *
 *   (1) BLOCK WRITE  smbacpi.c:208  memcpy(buf, gsb->data, gsb->len)
 *                                   gsb->len up to 255 -> 223-byte overflow
 *   (2) BYTES WRITE  smbacpi.c:223  memcpy(buf, gsb->data, info->AccessLength)
 *                                   AccessLength up to 255 -> same
 *   (3) BYTES READ   smbacpi.c:217  SMBUS_TRANS(..., buf, info->AccessLength, ...)
 *                   ig4_iic.c smb_transaction NOCNT branch writes rcount
 *                   bytes into rbuf -> same overflow
 *
 * BLOCK READ at :199-206 is NOT affected (count init 32, ig4 caps via
 * rcount>last check).
 *
 * The handler is invoked by ACPICA only when an ACPI AML method accesses a
 * GenericSerialBus OpRegion.  The audit guest's BOCHS DSDT contains no
 * such region, and the smbus_acpi driver never attaches (no
 * smb/smbacpi/ig4 in dmesg).  A realistic trigger requires:
 *  - malicious / buggy firmware,
 *  - root DSDT override via acpi_dsdt_load,
 *  - a malicious hypervisor controlling guest ACPI.
 *
 * None of those is an unprivileged attack surface on this guest, so the
 * bug is *latent* — confirmed by source trace.
 *
 * The fix is in fix.diff: size buf[] to ACPI_MAX_GSBUS_DATA_SIZE + 1 = 256
 * bytes so it can hold any ACPICA GSBUS data payload without overflow.
 */

int main(void) { return 0; }