In the Linux kernel, following vulnerability has been resolved: i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when resumes from S3 sleep state ("deep"). I was able debug issue Z690 AORUS ELITE and made following notes: - Issue happens resuming not from "s2idle" - PCI 00:15.0 == i2c_designware.0 is already in D0 when enters into pci_pm_resume_noirq() while all other i2c_designware devices are D3. Devices were runtime suspended D3 prior entering suspend - Interrupt comes after interrupts are re-enabled - According register dump interrupt really the i2c_designware.0. Controller enabled, I2C target address register points one detectable 0x60 DW_IC_RAW_INTR_STAT START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits set indicating completed transaction. My guess that firmware uses this controller communicate with an on-board during resume does disable controller before giving control an operating system. I told UEFI update fixes never less it revealed the driver ready handle (or RX_FULL) device is supposed be idle variables (especially the dev->msgs which may point or stale old data). Introduce new software status flag STATUS_ACTIVE the controller active driver view. Now treat interrupts that occur as mask from the controller.