CVE-2026-93068: drm/amd/display: Fix DM I2C teardown race

Published Sep 17, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix DM I2C teardown race

DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpudmi2cxfer() after the backing DM state has been torn down, leading to a NULL pointer dereference.

Create a devres group around the DM I2C adapter lifetime and release it at the start of dmhwfini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpudmi2cxfer() disappear.

This fixes a teardown ordering race seen during device removal:

BUG: kernel NULL pointer dereference RIP: amdgpudmi2cxfer+0x122/0x1c0 [amdgpu] Call Trace: i2ctransfer i2ctransfer i2cdevioctlrdwr

Affected Software

1 affected component

Linux Kernel

Event History

Sep 17, 2026

CVE Published

via MITRE·04:10 PM

Data Sourced

via MITRE·04:10 PM

Description

Frequently Asked Questions

What conditions are required to trigger the crash?

A userspace I2C transfer through i2c-dev must race with removal or teardown of the AMD display device. The transfer can reach amdgpu_dm_i2c_xfer() after its backing display-management state has already been removed.

What is the likely impact if the race occurs?

The kernel can dereference a NULL pointer in amdgpu_dm_i2c_xfer(), causing a kernel fault. The reported call trace includes __i2c_transfer, i2c_transfer, and i2cdev_ioctl_rdwr.

How can administrators recognize that they may have encountered this issue?

Look for a kernel NULL pointer dereference during device removal with amdgpu_dm_i2c_xfer in the instruction pointer or call trace. Affected traces may also show i2cdev_ioctl_rdwr leading into I2C transfer functions.