HIGH
acpi EC UAF
CVE-2026-31426
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI6.9MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: ACPI: EC: clean up handlers on probe failure in acpi_ec_setup() When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK> Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC
02KernelScan AI Analysis
Risk summary
Systems with reduced-hardware ACPI Embedded Controllers are vulnerable to kernel memory corruption when GPIO IRQ providers defer probing during boot. Any unprivileged user can trigger the use-after-free by reading battery, thermal, or backlight information through sysfs, potentially causing system crashes, limited information disclosure from heap reuse, or enabling privilege escalation.
Vulnerability analysis
The vulnerability occurs in the ACPI EC setup error path where ec_install_handlers() installs an address space handler but acpi_ec_setup() fails to clean it up on -EPROBE_DEFER errors. The caller then frees the struct acpi_ec, leaving a dangling pointer in ACPICA. Subsequent AML evaluation accessing EC OpRegion fields uses the freed pointer, causing use-after-free in acpi_ec_space_handler(). The fix adds proper cleanup by calling ec_remove_handlers() in the error path. Attack surface is local-only through sysfs reads but requires no privileges, making it accessible to any local user on affected reduced-hardware platforms.
03Fix Versions
| Branch | Fixed in | Patch commit |
|---|---|---|
| 6.1 | 6.1.168 | 022d1727f33f |
| 6.12 | 6.12.80 | 808c0f156f48 |
| 6.18 | 6.18.21 | d04c007047c8 |
| 6.19 | 6.19.11 | be1a827e1599 |
| 6.6 | 6.6.131 | 9c886e63b696 |
| mainline | 7.0 | f6484cadbcaf |