Cloudanix VulnDB

CVE-2026-90364

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Trigger conditions that cause driver_register or cpuhp_setup_state to fail inside acpi_processor_driver_init
  2. Allow the partial initialization error path to execute without unregistering the cpufreq notifier
  3. Induce a notifier callback via cpufreq policy changes or module exit
  4. 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