Cloudanix VulnDB

CVE-2026-99001

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in graphics hardware support code can cause the operating system kernel to access memory that has already been freed, potentially leading to crashes on affected Linux machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in drm/xe/i2c where a queued work item dereferences a DesignWare adapter after platform_device_unregister releases it and accesses a devm-freed xe_i2c struct; concurrent client array writes also occur during teardown.

Why it matters to the business

Linux systems using Intel Xe graphics may experience kernel instability or crashes during driver unload or device removal; low EPSS and absence from KEV indicate limited observed exploitation risk two days after disclosure.

How an attack unfolds

An attacker with local access triggers repeated i2c adapter registration and removal sequences to leave the i2c work item queued; the work then executes after the adapter is unregistered, dereferencing freed memory or racing on the client array.

How to fix it

Apply the upstream fix that moves bus_unregister_notifier before the client teardown loop and adds cancel_work_sync on i2c->work; rebuild and deploy updated kernel packages for affected distributions.

How to confirm the fix worked

Confirm the patch (cherry-pick of a23f27d5ec11) is present in the running kernel source; exercise device probe/remove cycles under memory debugging tools to verify no work executes after unregistration.

Typical attack path

  1. Obtain local code execution on a system with the xe i2c driver loaded
  2. Trigger platform device registration that schedules i2c->work via the bus notifier
  3. Initiate driver remove path that unregisters the notifier and adapter without canceling the work
  4. Allow the still-queued or running work to dereference the released adapter or freed memory

How to detect it

Review kernel logs for use-after-free warnings or oops during xe i2c adapter removal; inspect call traces referencing xe_i2c_notifier, xe_i2c_client_work, or i2c_new_client_device around device hot-unplug events.

What your security team should do

  • Prioritize kernel updates on systems exposing the xe i2c driver within standard patch windows given low EPSS
  • Monitor vendor kernel advisories for backported fixes in distribution releases
  • Test driver unload paths in staging environments with KASAN or similar to validate the work cancellation change

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe/i2c: cancel the client work on remove xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20)

Affected packages

Ecosystem Package Introduced Fixed