Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

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-&gt;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.

Impacto