Cloudanix VulnDB

CVE-2026-98825

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing issue in how the system gets a clock signal during startup can cause the whole machine to crash instead of waiting and trying again.

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

What it actually does

The probe function passes an unchecked error pointer returned by devm_clk_get for the rtcref clock directly to clk_get_rate, which dereferences the pointer instead of returning zero, resulting in a kernel crash rather than probe deferral.

Why it matters to the business

Systems may experience unexpected kernel crashes during boot or device initialization, leading to downtime, failed service starts, and operational instability on affected hardware.

How an attack unfolds

An attacker with the ability to influence device probing order or clock provider registration timing can trigger the error path in the RTC driver probe, causing the kernel to dereference an error pointer and panic, resulting in denial of service.

How to fix it

Apply the upstream kernel patch that captures the clock return value and checks it with IS_ERR before calling clk_get_rate; rebuild and deploy a fixed kernel image on affected systems.

How to confirm the fix worked

Review the rtc-mpfs driver source to confirm the IS_ERR check is present around the rtcref clock before clk_get_rate; test probe deferral scenarios and verify no crash occurs.

Typical attack path

  1. Gain local access or control over device initialization timing
  2. Arrange for the clock provider to not be registered when the mpfs RTC driver probes
  3. Trigger devm_clk_get to return an error pointer such as -EPROBE_DEFER
  4. Allow clk_get_rate to dereference the error pointer and crash the kernel

How to detect it

Inspect kernel logs and oops reports for dereference faults or probe failures involving the mpfs RTC or rtcref clock during early boot.

What your security team should do

  • Prioritize patching kernel images containing the mpfs RTC driver
  • Monitor boot logs for related clock or probe errors on PolarFire SoC systems
  • Test updated kernels in staging environments before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer: if (!clk) return 0; ... rate = clk_core_get_rate_recalc(clk->core); so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer. Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function.

Affected packages

Ecosystem Package Introduced Fixed