Skip to main content

Linux Kernel CVE-2022-50370

MEDIUM
NULL Pointer Dereference (CWE-476)
2025-09-17 416baaa9-dc9f-4396-8d5f-8c081fb06d67
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Analysis Generated
Mar 28, 2026 - 19:12 vuln.today
Patch released
Mar 28, 2026 - 19:12 nvd
Patch available
CVE Published
Sep 17, 2025 - 15:15 nvd
MEDIUM 5.5

DescriptionCVE.org

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.

AnalysisAI

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. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. This NULL Pointer Dereference vulnerability could allow attackers to crash the application by dereferencing a null pointer.

Technical ContextAI

This vulnerability is classified as NULL Pointer Dereference (CWE-476), which allows attackers to crash the application by dereferencing a null pointer. 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. Affected products include: Linux Linux Kernel.

RemediationAI

A vendor patch is available. Apply the latest security update as soon as possible. Check pointers before dereferencing. Use static analysis tools to detect null pointer paths.

CVE-2022-0847 HIGH POC
7.8 Mar 10

Linux kernel contains a flaw known as 'Dirty Pipe' where improper pipe buffer flag initialization allows unprivileged lo

CVE-2015-1328 HIGH POC
7.8 Nov 28

The overlayfs implementation in the linux (aka Linux kernel) package before 3.19.0-21.21 in Ubuntu through 15.04 does no

CVE-2017-7308 HIGH POC
7.8 Mar 29

The packet_set_ring function in net/packet/af_packet.c in the Linux kernel through 4.10.6 does not properly validate cer

CVE-2017-16995 HIGH POC
7.8 Dec 27

The check_alu_op function in kernel/bpf/verifier.c in the Linux kernel through 4.4 allows local users to cause a denial

CVE-2017-1000112 HIGH POC
7.0 Oct 05

Linux kernel: Exploitable memory corruption due to UFO to non-UFO path switch. Rated high severity (CVSS 7.0). Public ex

CVE-2015-8660 MEDIUM POC
6.7 Dec 28

The ovl_setattr function in fs/overlayfs/inode.c in the Linux kernel through 4.3.3 attempts to merge distinct setattr op

CVE-2012-0056 MEDIUM POC
6.9 Jan 27

The mem_write function in the Linux kernel before 3.2.2, when ASLR is disabled, does not properly check permissions when

CVE-2014-0038 MEDIUM POC
6.9 Feb 06

The compat_sys_recvmmsg function in net/compat.c in the Linux kernel before 3.13.2, when CONFIG_X86_X32 is enabled, allo

CVE-2016-8655 HIGH POC
7.8 Dec 08

Race condition in net/packet/af_packet.c in the Linux kernel through 4.8.12 allows local users to gain privileges or cau

CVE-2016-0728 HIGH POC
7.8 Feb 08

The join_session_keyring function in security/keys/process_keys.c in the Linux kernel before 4.4.1 mishandles object ref

CVE-2017-0561 CRITICAL POC
9.8 Apr 07

A remote code execution vulnerability in the Broadcom Wi-Fi firmware could enable a remote attacker to execute arbitrary

CVE-2022-2588 MEDIUM POC
5.3 Jan 08

It was discovered that the cls_route filter implementation in the Linux kernel would not remove an old filter from the h

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
Container suse/sle-micro-rancher/5.3:latest Container suse/sle-micro-rancher/5.4:5.4.4.5.72 Image SLES15-SP4-BYOS Image SLES15-SP4-BYOS-Azure Image SLES15-SP4-BYOS-EC2 Image SLES15-SP4-BYOS-GCE Image SLES15-SP4-CHOST-BYOS Image SLES15-SP4-CHOST-BYOS-Aliyun Image SLES15-SP4-CHOST-BYOS-Azure Image SLES15-SP4-CHOST-BYOS-EC2 Image SLES15-SP4-CHOST-BYOS-GCE Image SLES15-SP4-CHOST-BYOS-SAP-CCloud Image SLES15-SP4-HPC-BYOS Image SLES15-SP4-HPC-BYOS-Azure Image SLES15-SP4-HPC-BYOS-EC2 Image SLES15-SP4-HPC-BYOS-GCE Image SLES15-SP4-HPC-EC2 Image SLES15-SP4-HPC-GCE Image SLES15-SP4-Hardened-BYOS Image SLES15-SP4-Hardened-BYOS-Azure Image SLES15-SP4-Hardened-BYOS-EC2 Image SLES15-SP4-Hardened-BYOS-GCE Image SLES15-SP4-Manager-Proxy-4-3-BYOS Image SLES15-SP4-Manager-Proxy-4-3-BYOS-Azure Image SLES15-SP4-Manager-Proxy-4-3-BYOS-EC2 Image SLES15-SP4-Manager-Proxy-4-3-BYOS-GCE Image SLES15-SP4-Manager-Server-4-3-BYOS Image SLES15-SP4-Manager-Server-4-3-BYOS-Azure Image SLES15-SP4-Manager-Server-4-3-BYOS-EC2 Image SLES15-SP4-Manager-Server-4-3-BYOS-GCE Image SLES15-SP4-Micro-5-3 Image SLES15-SP4-Micro-5-3-BYOS Image SLES15-SP4-Micro-5-3-BYOS-Azure Image SLES15-SP4-Micro-5-3-BYOS-EC2 Image SLES15-SP4-Micro-5-3-BYOS-GCE Image SLES15-SP4-Micro-5-3-EC2 Image SLES15-SP4-Micro-5-4 Image SLES15-SP4-Micro-5-4-BYOS Image SLES15-SP4-Micro-5-4-BYOS-Azure Image SLES15-SP4-Micro-5-4-BYOS-EC2 Image SLES15-SP4-Micro-5-4-BYOS-GCE Image SLES15-SP4-Micro-5-4-EC2 Image SLES15-SP4-Micro-5-4-GCE Image SLES15-SP4-SAP Image SLES15-SP4-SAP-Azure Image SLES15-SP4-SAP-EC2 Image SLES15-SP4-SAP-GCE Image SLES15-SP4-SAPCAL Image SLES15-SP4-SAPCAL-Azure Image SLES15-SP4-SAPCAL-EC2 Image SLES15-SP4-SAPCAL-GCE Affected
Container suse/sle-micro/base-5.5:2.0.4-5.8.212 Image SLES15-SP5-BYOS-Azure Image SLES15-SP5-BYOS-EC2 Image SLES15-SP5-BYOS-GCE Image SLES15-SP5-CHOST-BYOS-Aliyun Image SLES15-SP5-CHOST-BYOS-Azure Image SLES15-SP5-CHOST-BYOS-EC2 Image SLES15-SP5-CHOST-BYOS-GCE Image SLES15-SP5-CHOST-BYOS-GDC Image SLES15-SP5-CHOST-BYOS-SAP-CCloud Image SLES15-SP5-EC2 Image SLES15-SP5-GCE Image SLES15-SP5-HPC-BYOS-Azure Image SLES15-SP5-HPC-BYOS-EC2 Image SLES15-SP5-HPC-BYOS-GCE Image SLES15-SP5-Hardened-BYOS-Azure Image SLES15-SP5-Hardened-BYOS-EC2 Image SLES15-SP5-Hardened-BYOS-GCE Image SLES15-SP5-Manager-Proxy-5-0-BYOS Image SLES15-SP5-Manager-Proxy-5-0-BYOS-Azure Image SLES15-SP5-Manager-Proxy-5-0-BYOS-EC2 Image SLES15-SP5-Manager-Proxy-5-0-BYOS-GCE Image SLES15-SP5-Manager-Server-5-0 Image SLES15-SP5-Manager-Server-5-0-Azure-llc Image SLES15-SP5-Manager-Server-5-0-Azure-ltd Image SLES15-SP5-Manager-Server-5-0-BYOS Image SLES15-SP5-Manager-Server-5-0-BYOS-Azure Image SLES15-SP5-Manager-Server-5-0-BYOS-EC2 Image SLES15-SP5-Manager-Server-5-0-BYOS-GCE Image SLES15-SP5-Manager-Server-5-0-EC2-llc Image SLES15-SP5-Manager-Server-5-0-EC2-ltd Image SLES15-SP5-Micro-5-5 Image SLES15-SP5-Micro-5-5-Azure Image SLES15-SP5-Micro-5-5-BYOS Image SLES15-SP5-Micro-5-5-BYOS-Azure Image SLES15-SP5-Micro-5-5-BYOS-EC2 Image SLES15-SP5-Micro-5-5-BYOS-GCE Image SLES15-SP5-Micro-5-5-EC2 Image SLES15-SP5-Micro-5-5-GCE Image SLES15-SP5-SAPCAL-Azure Image SLES15-SP5-SAPCAL-EC2 Image SLES15-SP5-SAPCAL-GCE Affected
Container suse/sle-micro/kvm-5.5:2.0.4-3.5.405 Affected
Container suse/sle-micro/rt-5.5:2.0.4-4.5.508 Affected
Image SLES15-SP4-SAP-Azure-LI-BYOS Image SLES15-SP4-SAP-Azure-LI-BYOS-Production Image SLES15-SP4-SAP-Azure-VLI-BYOS Image SLES15-SP4-SAP-Azure-VLI-BYOS-Production Image SLES15-SP4-SAP-BYOS Image SLES15-SP4-SAP-BYOS-Azure Image SLES15-SP4-SAP-BYOS-EC2 Image SLES15-SP4-SAP-BYOS-GCE Image SLES15-SP4-SAP-Hardened Image SLES15-SP4-SAP-Hardened-Azure Image SLES15-SP4-SAP-Hardened-BYOS Image SLES15-SP4-SAP-Hardened-BYOS-Azure Image SLES15-SP4-SAP-Hardened-BYOS-EC2 Image SLES15-SP4-SAP-Hardened-BYOS-GCE Image SLES15-SP4-SAP-Hardened-GCE Affected

Share

CVE-2022-50370 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy