UBUNTU-CVE-2026-99248: Medium severity ubuntu/linux vulnerability
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 pmruntimeenable()/disable() with devmpmruntimesetactiveenabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pmruntimedontuseautosuspend() before pmruntimedisable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devmclkgetenabled() release runs afterwards. At remove(), pmruntimeputsync() leaves the device active with the autosuspend timer armed. Clearing useautosuspend then makes rpmidle() suspend immediately, and xiici2cruntimesuspend() clkdisable()s the clock. The later devmclkgetenabled() release clkdisableunprepare()s the already-disabled clock, so clkcoredisable() 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: pmruntimedisable() followed by pmruntimeputnoidle() instead of pmruntimeputsync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pmruntimedisable() lets it expire, suspend the device and clkdisable() 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 requestthreadedirq() and free it explicitly in the probe error path and in remove. The probe error path also clears useautosuspend, to match the teardown in remove().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Restore non-managed runtime PM in the i2c: xiic driver: call pm_runtime_enable() once in probe, and during teardown call pm_runtime_disable() before pm_runtime_put_noidle() so the usage count is dropped only after runtime PM is disabled; do not use the managed helper or pm_runtime_put_sync(), and clear use_autosuspend on probe-error and remove paths.
- Compensating control
Restore non-managed IRQ handling: request the IRQ with request_threaded_irq(), and free it explicitly in both the probe error path and remove().
Event History
Frequently Asked Questions
Which systems are likely to encounter this issue?
Systems using the Xilinx IIC (xiic) kernel driver are the relevant population. The listed Ubuntu kernel packages include linux, linux-fips, and the AWS, Azure, GCP, and Oracle kernel variants, including their listed FIPS variants.
When is the problem triggered?
It occurs during device removal or teardown, after runtime PM usage handling leaves an autosuspend timer armed. The subsequent managed clock release can disable a clock that the runtime suspend path has already disabled.
How can I tell whether a system is affected?
Affected teardown operations produce repeated kernel clock warnings indicating that a clock is already disabled, such as "clkN already disabled." The description states this warning occurs on every affected teardown.
What does the fix change?
The fix restores non-managed runtime PM setup and teardown for the driver. It ensures runtime PM is disabled before its usage count is dropped and keeps the clock enable count balanced.