Description
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
Published: 2026-04-13
Score: 5.8 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Use‑after‑free leading to memory corruption
Action: Patch ASAP
AI Analysis

Impact

This kernel bug introduces a use‑after‑free that occurs when the ACPI EC install handler fails on reduced‑hardware platforms. The freed EC context remains registered with ACPICA and later AML evaluations that read EC OpRegion fields call the stale handler, corrupting kernel memory. The resulting memory corruption can allow an attacker with local access to influence kernel behaviour and possibly execute arbitrary code. The weakness is a classic use‑after‑free, classified as CWE‑825.

Affected Systems

The flaw affects all Linux kernel versions that contain the unpatched ACPI EC driver code. It is relevant for systems with ACPI support for embedded controllers, such as battery, thermal, and backlight OpRegions, that also use reduced‑hardware EC configurations (where the EC GPE is negative). The vulnerability is present regardless of the distribution or vendor, as it is a kernel source code defect shipped with upstream. Anyone running an unpatched kernel that uses ACPI EC on a platform that defers the EC probe is potentially impacted.

Risk and Exploitability

The CVSS score of 5.8 indicates moderate severity. No EPSS score is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, suggesting limited public exploitation at this point. The likely attack path requires local, unprivileged access to read a sysfs file that triggers an ACPI read on an EC OpRegion. While the vulnerability could be leveraged for privilege escalation or system instability, its exploitation is more likely to cause memory corruption or kernel crashes rather than immediate remote code execution. Consequently, patching remains the most effective countermeasure.

Generated by OpenCVE AI on April 14, 2026 at 01:37 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that incorporates the commit adding ec_remove_handlers() to the error path of acpi_ec_setup().
  • Verify that the kernel version includes the patch by checking the git commit hash or changelog.
  • For environments that cannot apply a full kernel upgrade immediately, consider disabling ACPI EC support or removing the EC OpRegion from the BIOS configuration to eliminate the attack surface.
  • Monitor kernel logs (dmesg, journal) for KASAN or memory corruption messages that would indicate the issue remains active.
  • Keep the system updated and review announcements from kernel maintainers for any related patches.

Generated by OpenCVE AI on April 14, 2026 at 01:37 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 14 Apr 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.8, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H'}

threat_severity

Moderate


Mon, 13 Apr 2026 13:45:00 +0000

Type Values Removed Values Added
Description 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
Title ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-13T13:40:29.635Z

Reserved: 2026-03-09T15:48:24.088Z

Link: CVE-2026-31426

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-04-13T14:16:12.600

Modified: 2026-04-13T15:01:43.663

Link: CVE-2026-31426

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-04-13T00:00:00Z

Links: CVE-2026-31426 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-14T16:34:22Z

Weaknesses