CVE-2026-90364
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A startup error in the Linux kernel can leave behind a piece of code that later causes the system to crash or be taken over by an attacker.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to unregister the cpufreq policy notifier on acpi_processor_driver_init failure leaves a dangling callback registered after the ACPI processor driver and idle driver have been torn down, resulting in a use-after-free when the notifier is later invoked.
Why it matters to the business
Linux-based systems may experience kernel instability, crashes, or potential privilege escalation, disrupting operations and requiring emergency patching across server and endpoint fleets.
How an attack unfolds
An attacker forces an error in driver_register or cpuhp_setup_state during ACPI processor initialization; the incomplete cleanup leaves the cpufreq notifier active; subsequent module unload or CPU policy events trigger the stale callback, dereferencing freed memory to achieve code execution or denial of service.
How to fix it
Apply the upstream kernel commit that unregisters the cpufreq notifier on the init failure path, matching the module-exit sequence; rebuild and deploy the fixed kernel across all affected distributions.
How to confirm the fix worked
Inspect acpi_processor_driver_init and the corresponding exit path in the kernel source to confirm symmetric notifier registration/unregistration; boot with forced init-failure injection and verify no dangling notifier remains.
Typical attack path
- Trigger conditions that cause driver_register or cpuhp_setup_state to fail inside acpi_processor_driver_init
- Allow the partial initialization error path to execute without unregistering the cpufreq notifier
- Induce a notifier callback via cpufreq policy changes or module exit
- Exploit the resulting use-after-free for memory corruption
How to detect it
Search kernel logs and crash dumps for ACPI processor initialization failure messages immediately followed by use-after-free or notifier-related oops; correlate with cpufreq policy change events.
What your security team should do
- Prioritize kernel updates on all Linux systems within the next patching cycle
- Enable kernel crash-dump collection and monitor for ACPI-related use-after-free signatures
- Review custom kernel configurations or out-of-tree ACPI drivers that may reintroduce similar error-handling gaps
The record
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Unregister cpufreq notifier on init failure acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|