Cloudanix VulnDB

CVE-2026-90422

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in the Linux kernel's handling of certain chip clocks can slowly waste memory if setup errors keep happening, which may eventually make the system unstable.

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

What it actually does

The flaw is a memory leak of IO mappings for the fhctl node in the error path of mtk_clk_register_pllfhs; the cleanup sequence omits the unmap that mtk_clk_unregister_pllfhs performs, and the loop index adjustment is also missing.

Why it matters to the business

On Linux systems using the affected MediaTek clock driver, repeated entry into the error path gradually exhausts IO mapping resources, which can degrade stability and require reboots after sustained operation.

How an attack unfolds

An attacker able to induce repeated PLL registration failures (via hardware configuration or injected errors) causes the kernel to map IO regions without freeing them on the error path, accumulating unreleased mappings until resource limits are hit.

How to fix it

Apply a kernel update that refactors the cleanup sequence into a shared private function used by both register and unregister paths and corrects the loop index start value.

How to confirm the fix worked

Inspect the pllfh driver source to confirm the shared cleanup helper exists and is invoked from both functions, and verify the loop index initialization no longer requires a post-decrement adjustment.

Typical attack path

  1. Trigger conditions that cause mtk_clk_register_pllfhs to fail after performing the IO map
  2. Bypass the missing unmap step in the local cleanup
  3. Repeat the failure sequence to accumulate leaked mappings

How to detect it

Watch kernel logs for repeated PLL registration failure messages from the mediatek driver and correlate with rising IO mapping or vmalloc usage via slabinfo or /proc/vmallocinfo.

What your security team should do

  • Prioritize kernel updates for any distribution or device tree using the mediatek pllfh driver
  • Test systems under error-injection workloads to confirm leak is closed
  • Monitor memory and IO mapping counters on production MediaTek-based platforms

The record

In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop.

Affected packages

Ecosystem Package Introduced Fixed