CVE-2026-89803 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: unsubscribe the channel-kill event before the fence context
nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown:
if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill);
The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed.
Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it.
Drop the subscription before anything it depends on is torn down.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's Nouveau DRM driver involves a race condition arising from incorrect resource teardown sequencing during channel deletion. Specifically, within the nouveau_channel_del function, the fence context associated with a graphics processing unit channel is destroyed prior to unsubscribing from the channel-kill event handler. This ordering creates a critical window where an asynchronous kill signal can be delivered while the underlying data structures are in an inconsistent state. The subscribed handler, nouveau_channel_killed(), invokes functions that attempt to access and lock the fence context structure which has already been freed by the preceding context_del call. Consequently, if a kill event arrives during this narrow interval, the kernel attempts to acquire locks on or traverse lists within memory that is no longer validly allocated for use, leading to undefined behavior such as use-after-free errors, potential data corruption, or system instability.
From a technical perspective, this flaw represents a classic race condition where synchronization primitives are not properly maintained during object lifecycle management. The issue stems from the dependency relationship between the event subscription and the fence context; the kill handler relies on the integrity of the fence context to perform cleanup operations like nouveau_fence_context_kill(). By tearing down the fence context before removing the subscription, the driver violates the principle that dependent resources must be released in reverse order of their creation or access. Although current hardware architectures above Fermi do not trigger this path due to gating mechanisms based on FERMI_CHANNEL_GPFIFO, and Tesla channels are similarly unaffected by existing kill logic, the vulnerability remains significant because it exposes a latent defect in the driver's state management. The existence of this window means that any future changes enabling channel kills for these architectures would immediately exploit this flaw, making proactive correction essential for long-term stability.
The operational impact of this vulnerability is primarily centered on system reliability and security posture rather than immediate remote exploitation. Since the race condition requires a precise timing coincidence where a kill event lands exactly during the teardown sequence, it is difficult to trigger intentionally without significant control over kernel scheduling or hardware interrupts. However, successful exploitation could lead to kernel panics, denial of service through system crashes, or potentially more severe consequences if memory corruption allows for code execution in kernel space. The vulnerability affects the integrity of the graphics subsystem and can compromise overall system stability, particularly under high-load scenarios where channel creation and destruction occur frequently.
This issue aligns with CWE-416, Use After Free, as it involves accessing a pointer to memory that has already been freed due to improper sequencing of deallocation operations. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, highlighting the failure to properly synchronize access to shared kernel structures during state transitions. In terms of MITRE ATT&CK mapping, this vulnerability falls under T1059, Command and Scripting Interpreter, specifically within the context of local privilege escalation or system compromise via exploitation of race conditions in kernel drivers, although its practical exploitability is currently limited by hardware-specific gating mechanisms.
To mitigate this risk, the recommended action is to reorder the teardown sequence so that the channel-kill event subscription is unsubscribed before any dependent resources like the fence context are destroyed. This ensures that no asynchronous handlers can access freed memory during the cleanup phase. Developers should review similar patterns in other DRM drivers and kernel subsystems where event subscriptions depend on dynamic data structures to prevent recurrence of such race conditions. Additionally, implementing robust debugging aids or static analysis tools capable of detecting use-after-free scenarios during object lifecycle management would help identify these issues earlier in the development cycle. For users running affected kernels, applying the upstream patch that corrects this ordering is critical to maintaining system stability and security integrity.