Live › vulnerability › CVE-2026-99248
A bug in the Linux kernel's xiic I2C controller driver tears down runtime power management in the wrong order on removal, so the clock is disabled twice and the kernel logs a warning on every teardown. The sources describe a warning flood, not a way for an attacker to gain access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 12:20 UTC. All times on this page are UTC.
Systems running a Linux kernel with the xiic I2C controller driver, typically embedded boards that use Xilinx I2C hardware, where the driver is bound and the device is removed or unbound. The sources describe a kernel log warning on teardown and do not describe a security exposure. Systems without this driver can skip it.
No product ranges from the sources yet.
uname -r to see the running kernel versionlsmod | grep xiicdmesgEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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().
This page as .md · .json · in your agent: get_signal("CVE-2026-99248")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.