linux-cve-announce - CVE-2022-50370: i2c: designware: Fix handling of real but unexpected device interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025091716-CVE-2022-50370-7271@gregkh>
Date: Wed, 17 Sep 2025 16:56:29 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50370: i2c: designware: Fix handling of real but unexpected device interrupts

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the 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 system resumes from S3 sleep state ("deep").

I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made
following notes:

- Issue happens when resuming from S3 but not when resuming from
  "s2idle"
- PCI device 00:15.0 == i2c_designware.0 is already in D0 state when
  system enters into pci_pm_resume_noirq() while all other i2c_designware
  PCI devices are in D3. Devices were runtime suspended and in D3 prior
  entering into suspend
- Interrupt comes after pci_pm_resume_noirq() when device interrupts are
  re-enabled
- According to register dump the interrupt really comes from the
  i2c_designware.0. Controller is enabled, I2C target address register
  points to a one detectable I2C device address 0x60 and the
  DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and
  TX_EMPTY bits are set indicating completed I2C transaction.

My guess is that the firmware uses this controller to communicate with
an on-board I2C device during resume but does not disable the controller
before giving control to an operating system.

I was told the UEFI update fixes this but never the less it revealed the
driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device
is supposed to be idle and state variables are not set (especially the
dev->msgs pointer which may point to NULL or stale old data).

Introduce a new software status flag STATUS_ACTIVE indicating when the
controller is active in driver point of view. Now treat all interrupts
that occur when is not set as unexpected and mask all interrupts from
the controller.

The Linux kernel CVE team has assigned CVE-2022-50370 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.12 with commit c7b79a75287141cef5bbaeaf1c942269c08cd52e and fixed in 5.15.75 with commit 7fa5304c4b5b425d4a0b3acf10139a7f6108a85f
	Issue introduced in 5.12 with commit c7b79a75287141cef5bbaeaf1c942269c08cd52e and fixed in 5.19.17 with commit a206f7fbe9589c60fafad12884628c909ecb042f
	Issue introduced in 5.12 with commit c7b79a75287141cef5bbaeaf1c942269c08cd52e and fixed in 6.0.3 with commit aa59ac81e859006d3a1df035a19b3f2089110f93
	Issue introduced in 5.12 with commit c7b79a75287141cef5bbaeaf1c942269c08cd52e and fixed in 6.1 with commit 301c8f5c32c8fb79c67539bc23972dc3ef48024c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50370
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/i2c/busses/i2c-designware-core.h
	drivers/i2c/busses/i2c-designware-master.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/7fa5304c4b5b425d4a0b3acf10139a7f6108a85f
	https://git.kernel.org/stable/c/a206f7fbe9589c60fafad12884628c909ecb042f
	https://git.kernel.org/stable/c/aa59ac81e859006d3a1df035a19b3f2089110f93
	https://git.kernel.org/stable/c/301c8f5c32c8fb79c67539bc23972dc3ef48024c