Live › vulnerability › CVE-2026-99001
Go to dashboardIn the Linux kernel's Intel Xe graphics I2C support, a deferred work item is not cancelled when the device is removed, so it can run against a freed adapter or freed memory. The sources do not say what an attacker gets beyond a kernel memory-safety crash or corruption.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the Intel Xe DRM driver and its I2C client support, typically machines with Intel Xe-based graphics where the AMC client is instantiated. Systems without the xe driver, or that are not running an affected kernel build, can skip it. The sources do not say which distributions or kernel versions are affected.
No product ranges from the sources yet.
uname -r and check whether the running kernel includes commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20 (unknown from the sources how to confirm this for a distribution kernel)lsmod | grep xe (unknown whether this is the exact check the sources intend)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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)
This page as .md · .json · in your agent: get_signal("CVE-2026-99001")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.