CVE-2026-99248

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().