CVE-2026-98825 in Linux
Summary
by MITRE • 10/18/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for the Microchip PolarFire SoC real-time clock presents a critical flaw rooted in improper error handling during device initialization. Specifically, within the probe function of the rtc_mpfs driver, the return value from devm_clk_get is passed directly to clk_get_rate without verifying whether it represents an error pointer or a valid clock handle. This oversight creates a scenario where invalid memory access can occur if the underlying hardware resources are not yet available during the probing phase. The vulnerability stems from a failure to validate pointers before dereferencing them, which violates fundamental principles of safe kernel programming and leads to system instability under specific timing conditions related to driver initialization order.
From a technical perspective, the core issue lies in the distinction between NULL pointers and error pointers returned by resource acquisition functions like devm_clk_get. While clk_get_rate includes a guard against NULL inputs returning zero, it does not handle error pointers such as ERR_PTR(-EPROBE_DEFER). When the clock provider has not yet registered its clocks, which is a common occurrence during early boot sequences or when dependencies are resolved out of order, devm_clk_get returns an encoded error pointer rather than NULL. Passing this invalid address to clk_get_rate results in dereferencing garbage memory addresses within the kernel space. This action triggers a general protection fault or page fault, causing a kernel panic and resulting in a denial of service for the entire system. The flaw is particularly insidious because it only manifests under specific race conditions regarding driver probe ordering, making it difficult to reproduce consistently without precise timing manipulation.
This vulnerability aligns with CWE-252, which describes unchecked return values, as well as CWE-476, concerning NULL pointer dereferences, although in this case the dereference is of an error pointer rather than a true null value. In terms of attack vectors and tactical classification under MITRE ATT&CK for Enterprise or ICS, this falls under T1595.002 Active Scanning: Vulnerability Scanning. An attacker with local access could potentially exploit this by manipulating the timing of device registration to force the probe function into a state where it attempts to dereference an invalid pointer. While primarily causing a denial of service through system crash, such instability can be leveraged in broader attack chains to disrupt critical infrastructure or industrial control systems that rely on stable kernel operations for real-time clock synchronization and hardware monitoring.
The operational impact of this vulnerability is severe due to the potential for immediate system crashes during boot or device hotplug events. For embedded systems utilizing Microchip PolarFire SoCs, a crash in the RTC driver can prevent the operating system from fully initializing, leading to unavailability of timekeeping services essential for logging, security certificates, and scheduled tasks. In industrial environments where these processors are often deployed, such instability could lead to unplanned downtime or loss of critical data integrity if the real-time clock fails to maintain accurate timestamps during recovery sequences. The lack of graceful degradation means that instead of deferring the probe until resources are available, the kernel terminates abruptly, requiring a full reboot and potentially masking other underlying issues by crashing before they can be diagnosed.
To mitigate this vulnerability, developers must implement robust error checking for all resource acquisition calls within driver probe functions. Specifically, the return value from devm_clk_get should be captured in a local variable and immediately checked using the IS_ERR macro before any subsequent operations are performed on it. If an error is detected, particularly ERR_PTR(-EPROBE_DEFER), the function should return that specific error code to allow the kernel driver core to defer the probe until dependencies are satisfied. This approach ensures that transient resource unavailability does not lead to fatal exceptions but rather triggers a controlled retry mechanism. Additionally, static analysis tools and automated testing frameworks should be configured to flag instances where devm_clk_get results are used without IS_ERR validation, reinforcing best practices for kernel memory safety and preventing similar defects in future code revisions.