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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The bug is reached only through the TI VIP V4L2 capture node: a local process open()s /dev/videoX, STREAMONs to arm parser/list-complete IRQs and overflow recovery, then STREAMOFF or close() tears the stream down. It is not reachable from network packets or a remote peer.
AC:L - The attacker starts streaming (which generates list-complete IRQs and can queue recovery_work) and then STREAMOFF/close, racing the hardirq and an already-queued worker that the old teardown never drained. Both sides of the race are attacker-induced and retryable, so this UAF is Low complexity.
PR:L - Exploitation needs only an unprivileged local user who can open the VIP /dev/videoX node and issue V4L2 streaming ioctls. On DRA7/AM57 embedded, industrial, and automotive systems that is typically the video group or a camera app, not root or init-namespace capabilities.
UI:N - The attacker performs open, STREAMON, and STREAMOFF/close themselves. No separate victim action such as mounting a filesystem or plugging in a device is required.
S:U - The UAF corrupts host-kernel stream and VPDMA descriptor state used by the same kernel that serves the ioctl. That is standard kernel memory corruption/privilege escalation, not a VM, IOMMU, or sandbox boundary crossing.
C:H - This is a use-after-free of the VPDMA descriptor list (freed on last file release) and of the stream object (freed on unbind/remove). The IRQ and recovery worker then read those objects, which per CVSS kernel UAF guidance enables kernel memory disclosure.
I:H - vip_overflow_recovery_work and the list-complete path write the freed descriptor buffer, rebuild DTDs, and resubmit VPDMA lists, giving a kernel write/DMA primitive suitable for control-flow hijack. UAF memory corruption is scored High integrity.
A:H - The same UAF and unlocked post_bufs/vidq walks from hardirq vs teardown oops or panic the kernel even when not fully exploited, so availability impact is High.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only through the TI VIP V4L2 capture node: a local process open()s /dev/videoX, STREAMONs to arm parser/list-complete IRQs and overflow recovery, then STREAMOFF or close() tears the stream down. It is not reachable from network packets or a remote peer.
AC:L - The attacker starts streaming (which generates list-complete IRQs and can queue recovery_work) and then STREAMOFF/close, racing the hardirq and an already-queued worker that the old teardown never drained. Both sides of the race are attacker-induced and retryable, so this UAF is Low complexity.
PR:L - Exploitation needs only an unprivileged local user who can open the VIP /dev/videoX node and issue V4L2 streaming ioctls. On DRA7/AM57 embedded, industrial, and automotive systems that is typically the video group or a camera app, not root or init-namespace capabilities.
UI:N - The attacker performs open, STREAMON, and STREAMOFF/close themselves. No separate victim action such as mounting a filesystem or plugging in a device is required.
S:U - The UAF corrupts host-kernel stream and VPDMA descriptor state used by the same kernel that serves the ioctl. That is standard kernel memory corruption/privilege escalation, not a VM, IOMMU, or sandbox boundary crossing.
C:H - This is a use-after-free of the VPDMA descriptor list (freed on last file release) and of the stream object (freed on unbind/remove). The IRQ and recovery worker then read those objects, which per CVSS kernel UAF guidance enables kernel memory disclosure.
I:H - vip_overflow_recovery_work and the list-complete path write the freed descriptor buffer, rebuild DTDs, and resubmit VPDMA lists, giving a kernel write/DMA primitive suitable for control-flow hijack. UAF memory corruption is scored High integrity.
A:H - The same UAF and unlocked post_bufs/vidq walks from hardirq vs teardown oops or panic the kernel even when not fully exploited, so availability impact is High.
CVSS 3.1