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