Cloudanix VulnDB

CVE-2026-98527

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A software bug in certain Linux systems can stop hardware from powering down properly, causing extra energy use and possible reliability problems on affected devices.

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

What it actually does

A runtime power management reference leak in the Zynq GPIO driver occurs when pm_runtime_get_sync fails in zynq_gpio_request; the usage counter is not decremented and gpiolib skips the free callback, so the only matching pm_runtime_put never executes, permanently disabling runtime suspend and leaving the clock enabled.

Why it matters to the business

Embedded devices using the affected driver may be unable to enter low-power states, resulting in higher power draw, reduced battery life, increased heat, and possible thermal throttling or shortened hardware lifespan.

How an attack unfolds

An attacker with local access on a Zynq-based system triggers a GPIO request that fails inside zynq_gpio_request, causing an unrecoverable PM reference leak that prevents the controller from ever suspending again.

How to fix it

Upgrade the Linux kernel to a version that replaces pm_runtime_get_sync with pm_runtime_resume_and_get inside the Zynq GPIO request handler so the usage counter is only incremented on success.

How to confirm the fix worked

Inspect the driver source for the corrected pm_runtime_resume_and_get call, exercise the error path in a test environment, and confirm via runtime PM debug interfaces that suspend/resume cycles resume normally after failed requests.

Typical attack path

  1. Obtain local unprivileged or privileged access to the Linux system
  2. Issue a GPIO request operation that hits the error path in the Zynq driver
  3. Trigger repeated failures to amplify the leak until runtime PM is permanently disabled
  4. Observe or leverage the resulting always-on clock for denial-of-service or side effects

How to detect it

Review kernel logs for GPIO request errors or runtime-PM warnings involving the Zynq driver; examine /sys/kernel/debug/pm_runtime or similar interfaces for stuck usage counters on the GPIO controller.

What your security team should do

  • Apply the upstream kernel fix as soon as a patched release is available
  • Restrict unprivileged access to GPIO character devices and sysfs interfaces
  • Monitor power-management and GPIO-related kernel logs on Zynq platforms
  • Test power-consumption baselines before and after the update on representative hardware

The record

In the Linux kernel, the following vulnerability has been resolved: gpio: zynq: fix runtime PM leak on request error path pm_runtime_get_sync() leaves the usage counter incremented even when it fails, and zynq_gpio_request() returns the error without dropping it. gpiolib does not call ->free() when ->request() fails, so zynq_gpio_free(), which holds the only matching pm_runtime_put(), never runs. The reference is leaked and the controller can no longer runtime-suspend, so its clock stays enabled. Switch to pm_runtime_resume_and_get(), which only increments the usage counter on success.

Affected packages

Ecosystem Package Introduced Fixed