CVE-2026-89893 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
media: cx23885: cancel NetUP CI work before teardown
netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state.
netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state.
Call cancel_work_sync() before dvb_ca_en50221_release() and kfree().
This issue was found by an in-house static analysis tool.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel media subsystem contains a concurrency vulnerability within the cx23885 driver, specifically affecting the NetUP CI (Common Interface) module implementation. This flaw arises from improper synchronization between device teardown procedures and asynchronous workqueue execution. The core issue lies in the netup_ci_exit function, which is responsible for freeing the netup_ci_state structure that manages the Common Interface hardware state. However, this deallocation occurs without ensuring that pending or currently executing worker tasks have completed their operations. Specifically, the netup_read_ci_status() worker item may still be queued on the system workqueue or actively running when the state memory is released. Since this worker function retrieves its context by using container_of to dereference a pointer to the now-freed state structure, it results in use-after-free behavior. This scenario allows for potential kernel crashes, data corruption, or arbitrary code execution if an attacker can influence the timing of these operations or exploit the freed memory region.
The root cause is rooted in the lifecycle management of interrupt handlers and workqueues during device removal. The initialization process involves queuing an initial status read via netup_ci_init(), while subsequent CI GPIO interrupts trigger additional queueing of this same worker through netup_ci_slot_status(). During the device unregistration phase, cx23885_finidev() invokes free_irq to disable further interrupt handling. While stopping new interrupts prevents fresh work items from being queued, it does not guarantee that previously queued or running workers will finish before memory is reclaimed. The Linux kernel's workqueue mechanism operates asynchronously relative to the calling thread, meaning there is no implicit synchronization point when an IRQ handler is disabled. Consequently, a race condition exists where the worker can access invalid memory after netup_ci_exit has deallocated it, leading to undefined behavior that compromises system stability and security.
From a vulnerability classification perspective, this issue aligns with CWE-416: Use After Free, as the code attempts to use a pointer to memory that has already been freed. Additionally, because the flaw involves improper synchronization between concurrent execution paths (the device removal thread and the workqueue worker), it also relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization. In terms of attack vectors, this could be leveraged for privilege escalation or denial of service depending on how the freed memory is reused by other kernel subsystems. The vulnerability was identified through static analysis tools designed to detect such race conditions and lifecycle mismatches in driver code, highlighting the importance of rigorous automated testing in kernel development pipelines.
To mitigate this vulnerability, it is necessary to ensure that all pending work items are cancelled and completed before any associated state structures are freed. This requires calling cancel_work_sync on the netup_ci_state's work item prior to invoking dvb_ca_en50221_release or performing kfree operations. The cancel_work_sync function not only prevents new executions but also blocks until any currently running instance of the worker completes, thereby guaranteeing that no thread will access the memory after it is deallocated. This synchronization step must be integrated into the teardown sequence to maintain data integrity and prevent kernel panics. Developers should review similar patterns in other media drivers to ensure consistent handling of asynchronous work items during device removal processes across the Linux kernel codebase.