CVE-2026-89893: media: cx23885: cancel NetUP CI work before teardown
In the Linux kernel, the following vulnerability has been resolved:
media: cx23885: cancel NetUP CI work before teardown
netupciexit() frees a netupcistate while its work item, netupreadcistatus(), may still be pending or running on the system workqueue. The worker obtains the state with containerof() and dereferences it, so it must not outlive the state.
netupciinit() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netupcislotstatus(). During remove, cx23885finidev() calls freeirq() before the CI device is unregistered. freeirq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netupciexit() frees the state.
Call cancelworksync() before dvbcaen50221release() and kfree().
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In cx23885 teardown paths, call cancel_work_sync() before calling dvb_ca_en50221_release() and before kfree() so the worker does not run after its state is freed (prevent outliving the state).
Linux kernel (media: cx23885) work item lifecycle ordering = Call cancel_work_sync() before dvb_ca_en50221_release() and kfree()
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel cx23885 media driver with NetUP CI support are exposed when the affected CI device is removed or torn down. The problem involves pending or running NetUP CI status work during device removal.
What conditions are required for exploitation or triggering?
A NetUP CI status-read work item must have been queued, either during CI initialization or by a CI GPIO interrupt, and device teardown must free the CI state before that work finishes. The queued worker can then dereference the freed state.
Does disabling the interrupt prevent the issue?
No. Calling free_irq() prevents new interrupt handlers from running, but it does not drain status work that was already queued on the system workqueue.
What mitigation is indicated if an update cannot be applied immediately?
The provided fix cancels and synchronizes the NetUP CI work before releasing and freeing its state. No separate operational workaround is provided in the available information.