CVE-2026-99001 in Linux
Summary
by MITRE • 10/23/2026
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)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in the Linux kernel's drm/xe/i2c subsystem represents a critical race condition and use-after-free flaw arising from improper synchronization during device removal. The core issue stems from the asynchronous nature of work queue execution combined with premature resource deallocation within the driver's teardown sequence. Specifically, when an xe I2C platform device is registered, the system stores the DesignWare adapter reference in the i2c structure and schedules a deferred work item via i2c->work. This scheduled task, executed by xe_i2c_client_work(), is responsible for instantiating an AMC client device on that specific adapter. However, during the removal phase handled by xe_i2c_remove(), the driver proceeds to tear down the AMC subsystem, unregister client devices, and unplug the bus notifier before ensuring that any pending or currently executing work items have completed their execution. This ordering creates a window where the underlying hardware abstraction layer is dismantled while background tasks still hold references to it.
The technical flaw manifests in two distinct but related failure modes: use-after-free memory corruption and data structure race conditions. First, because the work item is embedded within a devm-managed struct xe_i2c allocation, if this work item remains queued after the device manager unwinds and frees that memory block, the subsequent execution of its callback results in dereferencing freed memory. This leads to undefined behavior, potentially causing kernel panics or arbitrary code execution depending on how the freed memory is reused by other subsystems. Second, even without immediate memory corruption, there is a race condition involving the client array. The bus notifier unregistration occurs after the loop that iterates through and clears the i2c->client array. Consequently, if an instance of the work item was queued prior to this cleanup but has not yet started running, it may proceed to write into i2c->client[XE_I2C_CLIENT_AMC] while the teardown process is simultaneously clearing or unregistering that same slot. This concurrent access violates memory safety guarantees and can lead to data corruption within the kernel's I2C subsystem structures.
From a security perspective, this vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed due to incorrect lifecycle management of asynchronous tasks. Additionally, the race condition on shared data structures during teardown relates closely to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). In terms of offensive security frameworks such as MITRE ATT&CK, this type of vulnerability can be leveraged for privilege escalation or denial of service attacks. An attacker who can trigger the device removal process under specific timing conditions might exploit the race window to corrupt kernel memory, potentially gaining control over execution flow or causing a system crash to disrupt availability. The impact ranges from local denial of service through kernel oopses to potential remote code execution if the vulnerability is triggered in a context accessible by unprivileged users, although typically such driver-level issues require physical access or specific hardware interaction capabilities.
The remediation strategy implemented addresses these synchronization failures by reordering operations within the removal routine and explicitly canceling pending work items. The fix moves the bus_unregister_notifier() call to precede the client teardown loop, ensuring that no new instances of the work item can be scheduled once the cleanup process begins. Crucially, it introduces a cancellation step for i2c->work immediately after unregistering the notifier but before touching the client array or freeing resources. This ensures that any queued instance is drained and prevented from executing while the adapter structure remains valid. By keeping the adapter unregistered until after the work item has been safely canceled and potentially completed, the fix guarantees that a running instance will always find a live adapter object to operate on. This approach restores proper synchronization between asynchronous task execution and resource deallocation, eliminating both the use-after-free condition and the race condition on shared data structures. System administrators should ensure their kernels are updated with this patch to mitigate risks associated with driver instability and potential exploitation of memory safety violations in I2C subsystem interactions.