CVE-2026-23055
Unknown Unknown - Not Provided
Improper Suspend Handling in Linux i2c riic Driver Causes System Warnings

Publication date: 2026-02-04

Last updated on: 2026-02-04

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: i2c: riic: Move suspend handling to NOIRQ phase Commit 53326135d0e0 ("i2c: riic: Add suspend/resume support") added suspend support for the Renesas I2C driver and following this change on RZ/G3E the following WARNING is seen on entering suspend ... [ 134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 134.285536] ------------[ cut here ]------------ [ 134.290298] i2c i2c-2: Transfer while suspended [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388 [ 134.365507] Tainted: [W]=WARN [ 134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT) [ 134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214 [ 134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214 [ 134.391717] sp : ffff800083f23860 [ 134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60 [ 134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001 [ 134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936 [ 134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006 [ 134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280 [ 134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09 [ 134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8 [ 134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000 [ 134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000 [ 134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80 [ 134.466851] Call trace: [ 134.469311] __i2c_smbus_xfer+0x1e4/0x214 (P) [ 134.473715] i2c_smbus_xfer+0xbc/0x120 [ 134.477507] i2c_smbus_read_byte_data+0x4c/0x84 [ 134.482077] isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208] [ 134.487703] isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208] [ 134.493226] __rtc_read_time+0x44/0x88 [ 134.497012] rtc_read_time+0x3c/0x68 [ 134.500622] rtc_suspend+0x9c/0x170 The warning is triggered because I2C transfers can still be attempted while the controller is already suspended, due to inappropriate ordering of the system sleep callbacks. If the controller is autosuspended, there is no way to wake it up once runtime PM disabled (in suspend_late()). During system resume, the I2C controller will be available only after runtime PM is re-enabled (in resume_early()). However, this may be too late for some devices. Wake up the controller in the suspend() callback while runtime PM is still enabled. The I2C controller will remain available until the suspend_noirq() callback (pm_runtime_force_suspend()) is called. During resume, the I2C controller can be restored by the resume_noirq() callback (pm_runtime_force_resume()). Finally, the resume() callback re-enables autosuspend. As a result, the I2C controller can remain available until the system enters suspend_noirq() and from resume_noirq().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-02-04
Generated
2026-05-06
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
renesas i2c *-*
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Renesas I2C driver in the Linux kernel where I2C transfers can be attempted while the controller is already suspended. This happens due to improper ordering of system sleep callbacks.

Specifically, after adding suspend support, the system may try to transfer data over I2C during suspend, triggering warnings and potential issues because the controller is not properly available during certain suspend phases.

The root cause is that if the controller is autosuspended, it cannot be woken up once runtime power management is disabled during the suspend process, making the controller unavailable too early.

The fix moves suspend handling to the NOIRQ phase, ensuring the I2C controller remains available until the appropriate suspend_noirq callback and is restored early enough during resume, preventing transfers while suspended.


How can this vulnerability impact me? :

This vulnerability can cause system warnings and instability during suspend and resume cycles on affected hardware using the Renesas I2C driver.

If I2C transfers are attempted while the controller is suspended, it may lead to failed communications with I2C devices, potentially causing malfunction or data loss in components relying on I2C.

In embedded or hardware-dependent systems, this could result in degraded system reliability or unexpected behavior during power management operations.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing specific WARNING messages in the system logs related to I2C transfers during suspend. The key indicator is a warning message similar to:

  • [ 134.290298] i2c i2c-2: Transfer while suspended
  • [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388

To detect this on your system, you can check the kernel log for such warnings using commands like:

  • dmesg | grep 'i2c.*Transfer while suspended'
  • journalctl -k | grep 'i2c.*Transfer while suspended'
  • journalctl -k | grep WARNING | grep i2c

What immediate steps should I take to mitigate this vulnerability?

The vulnerability arises because I2C transfers are attempted while the controller is suspended due to improper ordering of system sleep callbacks.

To mitigate this issue immediately, ensure that the I2C controller is woken up during the suspend() callback while runtime power management (PM) is still enabled. This allows the controller to remain available until the suspend_noirq() callback.

During resume, the controller should be restored in the resume_noirq() callback, and autosuspend should be re-enabled in the resume() callback.

If you are managing kernel code or device drivers, apply the patch or commit that moves suspend handling to the NOIRQ phase, as described in commit 53326135d0e0.

If you are an end user, update your Linux kernel to a version that includes this fix to prevent the warning and potential issues.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart