Summary

EcSpaceHandler validates that Width is a multiple of 8 and that Address + Width/8 <= 256, but never enforces Width <= 64. The data pointer EcData is cast from UINT64 *Value (8 bytes); the do/while loop at lines 853–866 walks EcData++ once per byte up to Address + Width/8 times. For any Width > 64 (e.g. 128, 256) where Address + Width/8 <= 256, the loop writes past the 8-byte UINT64 storage on the ACPICA interpreter stack. ACPICA's own region-dispatch contract (contrib/dev/acpica/source/components/events/evregion.c:240) explicitly states BitWidth is one of {8, 16, 32, 64}; the handler is required to enforce this and does not.

Root cause

EcSpaceHandler (sys/dev/acpica/acpi_ec.c:805) checks only:

if (Width % 8 != 0 || Value == NULL || Context == NULL)   /* line 818 */
    return_ACPI_STATUS (AE_BAD_PARAMETER);
if (Address + Width / 8 > 256)                            /* line 820 */
    return_ACPI_STATUS (AE_BAD_ADDRESS);

There is no if (Width > 64) return AE_BAD_PARAMETER;. The transaction loop at lines 849–866 does:

EcData = (UINT8 *)Value;                                  /* line 850 */
do {
    ...
    if (Function == ACPI_READ)
        EcRead(sc, EcAddr, EcData);   /* writes *EcData = EC_GET_DATA */
    else
        EcRead(sc, EcAddr, EcData);   /* reads *EcData for the write path */
    EcData++;
    EcAddr++;
} while (EcAddr < Address + Width / 8);

For Address = 0, Width = 256: the address check 0 + 32 > 256 is FALSE so it passes, but the loop then writes 32 bytes through a pointer to an 8-byte UINT64. The same hole exists for Width = 128 (+8 OOB), Width = 192 (+16 OOB), etc.

On the ACPI_READ path each iteration calls EcRead(sc, EcAddr, EcData) which writes *EcData = EC_GET_DATA(sc) at sys/dev/acpica/acpi_ec.c:1041 — a linear stack overwrite of (Width/8 - 8) bytes. On the ACPI_WRITE path each iteration reads *EcData at line 859 — an OOB read of caller stack.

Threat model / reachability

Triggering the bug requires either:

1. Custom ACPI table: an attacker able to load an ACPI SSDT (e.g. via the bootloader, kldloadable ACPI override, or malicious firmware on a VM host) can declare an EC OperationRegion field with a non-standard access width > 64. Standard AML never produces Width > 64: AcpiExDecodeFieldAccess at contrib/dev/acpica/source/components/executer/exprep.c:350-430 clamps to {8,16,32,64}.
2. In-kernel buggy caller of acpi_ec_read_method/acpi_ec_write_method (acpi_ec.c:622,635) passing width >= 9 (since width*8 becomes Width >= 72).

All 39 in-tree ACPI_EC_READ/ACPI_EC_WRITE callers (acpi_smbat.c, acpi_thinkpad.c, acpi_wii.c) pass width = 1 or 2 — safe under the current code base. Not reachable by an unprivileged local user under the default threat model. Hence Low, not Critical, despite the kernel corruption primitive when triggered.

Impact (if triggered)

Kernel stack buffer overflow in the ACPICA interpreter context — Value typically points at a UINT64 local in AcpiEvAddressSpaceDispatch's caller. Corrupting up to 248 bytes past the 8-byte storage could overwrite saved registers / return address on the interpreter stack → local kernel- mode code execution from a privileged trigger.

PoC

findings/poc/DF-1649/:

• ssdt.asl — SSDT source declaring an EC field with AnyAcc width 256
• ssdt.aml — precompiled (or iasl ssdt.asl to rebuild)
• trigger.sh — boots qemu-system-x86_64 -acpitable file=ssdt.aml ... and shows the panic signature from the corrupted interpreter stack.
• Alternative: mod_oob.c — a kldloadable module that calls ACPI_EC_READ(ec_dev, 0, &val, 9) (width 9 → Width = 72), runnable only as root, demonstrating the overwrite directly.

Expected: kernel panic with stack corruption in EcSpaceHandler / EcRead, or a controlled overwrite if the heap is groomed.

Recommended fix

Add an explicit upper bound on Width, matching the ACPICA region-handler contract. Linux enforces the equivalent check in drivers/acpi/ec.c.

--- a/sys/dev/acpica/acpi_ec.c
+++ b/sys/dev/acpica/acpi_ec.c
@@ -816,8 +816,11 @@ EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 Width,

     if (Function != ACPI_READ && Function != ACPI_WRITE)
    return_ACPI_STATUS (AE_BAD_PARAMETER);
-    if (Width % 8 != 0 || Value == NULL || Context == NULL)
+   /* ACPICA region-handler contract: Width is 8, 16, 32, or 64 bits. */
+    if (Width == 0 || Width > 64 || (Width & (Width - 1)) != 0 ||
+   Value == NULL || Context == NULL)
    return_ACPI_STATUS (AE_BAD_PARAMETER);
-    if (Address + Width / 8 > 256)
+   if (Address + Width / 8 > 256)
    return_ACPI_STATUS (AE_BAD_ADDRESS);

The (Width & (Width - 1)) != 0 test rejects non-power-of-two widths (e.g. 24, 40) that ACPICA never legitimately passes to an EC handler but that the loop math at line 866 would otherwise honor. Width == 0 is rejected because the do/while runs at least once regardless and would silently read one byte while reporting success for a zero-width field.

References

• ACPICA contract: contrib/dev/acpica/source/components/events/evregion.c:240
• AML width clamping: contrib/dev/acpica/source/components/executer/exprep.c:350-430
• Linux equivalent: drivers/acpi/ec.c (acpi_ec_space_handler)