Skip to content
Fencer Intel
no cvss —

CVE-2026-99001 json

drm/xe/i2c: cancel the client work on remove

published 19d ago modified 19d ago also EUVD-2026-108795

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 5%
public exploits
0
none known

Summary

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)

Patch / fix

  • Linux Linux 7.3
  • linux Debian 14 7.2.11-1

debian advisories DEBIAN-CVE-2026-99001

  • linux Ubuntu 26.10 7.3.0-10.10
  • linux-aws Ubuntu 26.10 7.3.0-1004.4
  • linux-gcp Ubuntu 26.10 7.3.0-1004.4
  • linux-raspi Ubuntu 26.10 7.3.0-1004.4
  • linux-riscv Ubuntu 26.10 7.3.0-10.10.1
  • linux-oracle Ubuntu 26.10 7.3.0-1004.4
  • linux-realtime Ubuntu 26.10 7.3.0-10.10.1

ubuntu advisories UBUNTU-CVE-2026-99001

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

Is CVE-2026-99001 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-99001 updated cvss 4.1

kernel: drm/xe/i2c: cancel the client work on remove

  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-selftests-internal Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.17% chance of exploitation in the next 30 days, higher than 5% of all scored CVEs (FIRST EPSS, 2026-11-11).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.