CVE Catalog

CVE-2026-89875

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Summary

In the Linux kernel, the VPE (Video Processing Engine) driver for TI platforms has a vulnerability due to missing synchronization between the FIFO overflow recovery worker and IRQ handling during stream teardown. This can lead to use-after-free of stream resources when an interrupt or worker runs after the stream is released.

Risk Assessment

The risk includes system crash (panic) or potential privilege escalation in environments with access to TI video hardware. A local attacker could exploit the flaw to compromise kernel integrity.

Recommendation

Apply the official Linux kernel patch that adds the vip_quiesce_stream() helper to synchronize the worker and IRQs before releasing resources. Update the system to a patched kernel version.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: quiesce overflow recovery before freeing streams The VIP overflow recovery worker is armed from the hardirq handler when a FIFO overflow is detected, and the list-complete path looks the stream up through the VPDMA list private pointer. Both keep touching stream, port and device state; the recovery worker also resets the parser and VPDMA, repopulates the descriptor list, and re-enables the per-list IRQs. vip_stop_streaming() masks and clears the per-list IRQs, but it neither synchronizes the hardirq handler nor disables recovery_work. An overflow IRQ that has already queued recovery_work, or a list-complete IRQ in flight when the stream is torn down, can therefore still dereference the stream after its resources are released: the descriptor list is freed by vip_release_stream() on file release, and the stream itself by free_stream() on unbind/remove. Drain the recovery worker and the IRQ handler at both teardown points through a shared vip_quiesce_stream() helper, before any stream-owned resource is released. disable_work_sync() cancels pending recovery_work, drains a running instance, and raises its disable depth, so a subsequent schedule_work() issued by a racing IRQ handler is rejected at the workqueue scheduler: recovery_work cannot be requeued after disable_work_sync() takes effect. The worker may still re-enable the per-list IRQs before disable_work_sync() returns; disable_irqs() then masks those sources and synchronize_irq() waits for any in-flight handler that still dereferences stream state. In vip_stop_streaming() the helper runs before the parser is stopped, since a worker drained by disable_work_sync() may re-enable the parser before exiting and would otherwise undo the stop. recovery_work is created disabled and enabled in vip_start_streaming() before IRQs, pairing the enable with the teardown disable across the streaming lifecycle. This issue was found by an in-house static analysis tool and confirmed by manual code review.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS