CVE-2026-64183 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
efi: Allocate runtime workqueue before ACPI init
Since commit
5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")
ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.
Rafael reports that such PRM accesses may occur before efisubsys_init() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpi_init() [which triggers the early PRM
accesses] executes as a subsys_initcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpi_init() is not an option.
So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsys_initcall() level.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability represents a critical race condition in the Linux kernel's early initialization sequence involving EFI runtime services and ACPI subsystem integration. The issue stems from a fundamental timing dependency problem where ACPI PRM (Processor Runtime Management) handler invocations attempt to access EFI runtime workqueues before they have been properly allocated during the kernel boot process. This creates a scenario where firmware handlers can execute against uninitialized memory structures, resulting in system crashes through NULL pointer dereferences.
The technical flaw manifests from the commit 5894cf571e14 which introduced a security enhancement by delegating ACPI PRM calls to a dedicated workqueue running in a kernel thread. This design was intended to provide better fault isolation and memory access monitoring for potentially malicious firmware components. However, the implementation failed to account for the execution order dependencies within the Linux kernel initialization framework where acpi_init() runs as a subsys_initcall() and may invoke PRM handlers before efisubsys_init() has completed its workqueue allocation. The subsystem initialization order is critical in kernel design and cannot be easily modified due to complex dependency chains that other components rely upon.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation attacks through controlled kernel memory corruption. When firmware handlers execute before the runtime workqueue exists, they can trigger NULL pointer dereferences that may allow malicious firmware to manipulate kernel execution flow or cause denial of service conditions affecting critical system functionality. This vulnerability particularly affects systems relying on UEFI firmware integration and ACPI power management features during early boot phases.
The mitigation strategy involves splitting the workqueue allocation into its own postcore initcall, which executes after the core kernel subsystems but before the more complex subsys_initcall dependencies. This architectural change ensures that EFI runtime capabilities including PRM calls are available to all code running at subsys_initcall() level without creating race conditions. The solution aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and addresses ATT&CK technique T1059.006 (Windows Command Shell) through proper kernel initialization sequence management. This approach maintains the security benefits of the original PRM handler isolation while eliminating the timing race condition that led to system instability.
The fix demonstrates proper adherence to Linux kernel initialization best practices by ensuring resource allocation precedes usage regardless of execution context dependencies. This vulnerability highlights the complexity of modern kernel boot processes where multiple subsystems must coordinate initialization without creating circular dependencies or race conditions. The resolution prevents unauthorized access patterns during early boot while maintaining the security posture intended by the original EFI runtime sandboxing mechanism. This type of vulnerability commonly affects enterprise systems and servers that rely heavily on UEFI firmware integration and ACPI power management during critical boot phases.