Cloudanix VulnDB

CVE-2026-89572

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in the Linux kernel code that manages power settings on Apple processors could leave behind data during startup errors and make those systems less stable.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability stems from apple_soc_cpufreq_init() adding OPP tables from firmware without guaranteed removal on failure paths, combined with use of the incorrect dev_pm_opp_remove_all_dynamic() helper instead of cpumask-based removal after policy CPU mask population.

Why it matters to the business

Systems running Linux on Apple Silicon hardware risk kernel resource leaks or instability during cpufreq initialization errors, which can degrade power management reliability and increase operational overhead for affected devices.

How an attack unfolds

A local attacker triggers error conditions in the cpufreq initialization sequence on Apple SoC platforms to leave OPP tables unreleased, resulting in gradual kernel memory exhaustion or unexpected driver behavior that can be leveraged for denial of service.

How to fix it

Update the Linux kernel to the version containing the cpufreq apple-soc fix that switches to cpumask OPP helpers paired with matching removal on all failure paths and in the exit routine.

How to confirm the fix worked

Inspect the apple_soc_cpufreq source to confirm dev_pm_opp_add_opps_from_dt() or equivalent cpumask helper is called after policy CPU mask population and that the corresponding cpumask remove helper is used on every exit path.

Typical attack path

  1. Gain local execution on a Linux system using the apple-soc cpufreq driver
  2. Force failure paths in apple_soc_cpufreq_init() by manipulating DT or policy setup
  3. Repeat the triggering condition to accumulate unreleased OPP tables
  4. Induce resource pressure leading to system instability or crashes

How to detect it

Review kernel logs for cpufreq and OPP table allocation messages on Apple SoC hardware, especially entries showing init failures without corresponding cleanup; correlate with memory usage anomalies in the power management subsystem.

What your security team should do

  • Prioritize kernel updates on all Apple Silicon Linux deployments
  • Test cpufreq initialization under error conditions after patching
  • Review device tree configurations for the affected platforms

The record

In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix OPP table cleanup apple_soc_cpufreq_init() adds OPP tables from firmware, but some failure paths do not remove them. The driver also uses dev_pm_opp_remove_all_dynamic(), which is not the right cleanup helper for OPP tables loaded from firmware. Use the cpumask OPP helper after the policy CPU mask has been populated. Pair it with the matching cpumask remove helper on failure paths and in apple_soc_cpufreq_exit(). This also removes the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask helper loads the DT OPP tables for all CPUs in the policy.

Affected packages

Ecosystem Package Introduced Fixed