# DF-1112 — VERDICT

**Verdict: NOT REPRODUCED at runtime (latent — requires ACPI AML with a
GSBUS opregion; the BOCHS firmware DSDT has none, and the smbus_acpi
driver never attaches).  Bug confirmed by source trace.**

## Mechanism (source-confirmed)

`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 (2-byte header +
`ACPI_MAX_GSBUS_DATA_SIZE = 255` data bytes — see
`sys/contrib/dev/acpica/source/include/acconfig.h:332`) for
`ATTRIB_BLOCK(0x0A)` and `ATTRIB_BYTES(0x0B)` transfers and passes the
data portion to this handler.  Three overflow paths:

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 at line 200 and `ig4_iic.c` caps via its
`rcount > last` check.

The attacker controls the ACPI AML.  Trigger surfaces:
- malicious / buggy firmware,
- root-triggered DSDT override via `acpi_dsdt_load`,
- a malicious hypervisor controlling guest ACPI.

## Why it can't be triggered on this guest

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

The BOCHS firmware DSDT is 0x1AF8 bytes and contains only standard
devices (no GSBUS opregion declaration).  The `smbus_acpi` driver never
attaches because there is no ACPI-enumerated I2C controller with a GSBUS
opregion on this guest, so `smbus_acpi_space_handler` is never even
registered with ACPICA, let alone invoked.

Even with a malicious DSDT loaded via `acpi_dsdt_load`, the trigger
requires `root` (loading a DSDT is a privileged action), so this is not
an unprivileged attack surface.

## Exploit chain

**Primitive class:** stack buffer overflow (up to ~223 bytes) with both
size and content controlled by attacker-controlled ACPI AML.  On a kernel
without stack protector for this path (and KASLR off), this could in
principle overwrite the return address → control-flow hijack →
`commit_creds(prepare_kernel_cred(0))` chain.

BUT:

- The trigger requires either malicious firmware or a `root` DSDT
  override.  Root→kernel is game-over by definition; there is no
  privilege boundary to cross.
- The handler is never invoked on this guest.

**Valid hard blocker** ("vulnerable code path is dead code at runtime on
this guest AND no harness can exercise it without hardware/firmware the
guest lacks").  Documented as latent.  No `uid=0` achievable from an
unprivileged context on this guest.

## Fix

`fix.diff` resizes `buf[]` from `char buf[32]` to
`char buf[ACPI_MAX_GSBUS_DATA_SIZE + 1]` (= 256 bytes), large enough to
hold any ACPICA GSBUS data payload without overflow.  This matches
ACPICA's own buffer sizing.  Validated as applies + compiles in a clean
GENERIC kernel build.

## Fix validation

`not_testable` — path not runtime-reachable on this guest.  Validated
`fix.diff` applies cleanly and compiles with `-Werror` in a full
`make nativekernel KERNCONF=X86_64_GENERIC` (smbacpi.o rebuilt fresh, no
warnings/errors — see `../DF-1096/all_fixes_build.log`).

## PoC changes

- Wrote `df1112.c` (documentation-only stub explaining the source trace).
- Wrote `fix.diff`, `build.sh`, `run.sh`.