CVE-2026-99248 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
i2c: xiic: restore non-managed runtime PM to fix clk WARN flood
The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards.
At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown.
Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced.
Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN.
Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel driver for the Xilinx I2C controller experienced a critical resource management flaw resulting from an improper conversion to managed device resources. This vulnerability stems from the replacement of manual power management and interrupt request handling with devres helpers, which inadvertently introduced race conditions and double-free scenarios during device removal or probe failure sequences. The core issue lies in the incorrect ordering of runtime power management teardown operations combined with the lifecycle mismatch between manually handled hardware state and automatically managed resources. When the driver was updated to use devm_pm_runtime_set_active_enabled(), it removed explicit calls to pm_runtime_enable() and pm_runtime_disable(). However, this change failed to account for the Last-In-First-Out nature of device resource management. Consequently, during the removal phase, the runtime power management subsystem is disabled after certain other resources have already been released or altered in a way that assumes those resources are still active.
The technical flaw manifests specifically when pm_runtime_put_sync() is invoked while autosuspend remains enabled. This action leaves the device in an active state with its autosuspend timer armed. If preemption occurs before the subsequent call to clear use_autosuspend, the timer may expire immediately, triggering rpm_idle(). This function calls xiic_i2c_runtime_suspend(), which disables the hardware clock via clk_disable(). Subsequently, when the devres system unwinds and releases the managed clock handle obtained earlier in probe, it attempts to disable and unprepare a clock that has already been disabled by the runtime suspend path. This results in a kernel warning indicating that the clock is already disabled, effectively creating a double-disable condition on the hardware resource. While this primarily generates log noise under normal operation, it indicates a fundamental violation of reference counting principles where resources are released without proper synchronization or state awareness.
Beyond the immediate power management issue, the vulnerability extends to interrupt request handling and error path unwinding in the probe function. The previous implementation relied on devm-registered handlers for interrupts, which persist until the end of device resource cleanup. However, manual teardown routines executed earlier during error paths would disable runtime power management while these managed interrupt handlers remained active. This created a window where an interrupt could fire against a partially torn-down hardware state or trigger logic that expected certain power states to be maintained. Furthermore, probe failure paths did not correctly unwind the autosuspend configuration, leading to inconsistent driver state if initialization failed partway through. These issues collectively represent a breakdown in the atomicity of device setup and teardown procedures, allowing for race conditions between asynchronous timer expirations and synchronous resource release sequences.
From a classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition arises from unsynchronized access to hardware clock state by both runtime power management timers and devres cleanup routines. It also relates to CWE-401: Missing Release of Memory after Effective Lifetime, specifically regarding improper release of system resources like clocks and interrupts during error handling paths. In terms of attack surface or operational impact, while this is not a direct remote code execution vector, it can lead to kernel instability, denial of service through repeated warning floods that may exhaust logging buffers or trigger panic-on-warn configurations in hardened systems, and potential hardware state corruption if the clock disable sequence causes undefined behavior in downstream components. The ATT&CK framework does not directly map this specific driver bug to a tactical technique as it is an internal kernel logic error rather than an exploit vector for external attackers; however, its impact on system stability falls under T1499: Endpoint Denial of Service if the warnings cause significant performance degradation or crashes in production environments.
To mitigate these issues and restore robust operation, the driver code was modified to revert from managed power management helpers back to explicit manual control over runtime PM lifecycle events. This ensures that pm_runtime_enable() is called exactly once during probe and pm_runtime_disable() is called exactly once during remove, maintaining a balanced reference count for hardware resources. The order of operations in the removal sequence was strictly corrected so that runtime power management is disabled before dropping usage counts with pm_runtime_put_noidle(), preventing the autosuspend timer from triggering suspend logic after the device has been logically detached. Additionally, interrupt requests are now handled explicitly using request_threaded_irq() and freed manually during both successful remove operations and probe error paths. This guarantees that no managed handlers remain active when manual teardown occurs, eliminating the race condition between devres cleanup and hardware state changes. These fixes ensure that clock enable counts remain balanced across all execution paths, including failure scenarios, thereby preventing double-disable warnings and maintaining system stability.