CVE-2026-89875 (GCVE-0-2026-89875)
Vulnerability from cvelistv5
Published
2026-09-16 10:31
Modified
2026-10-19 08:54
Summary
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.
Impacted products
Vendor Product Version
Linux Linux Version: fc2873aa4a21355593b55eb49ff534d31f81c584
Version: fc2873aa4a21355593b55eb49ff534d31f81c584
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/media/platform/ti/vpe/vip.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "fd5b4a14c87b21e1c9eaee603b01bb7fa7db45c8",
              "status": "affected",
              "version": "fc2873aa4a21355593b55eb49ff534d31f81c584",
              "versionType": "git"
            },
            {
              "lessThan": "aeaacc3001449d44b4ab7da56331121d1f3b137b",
              "status": "affected",
              "version": "fc2873aa4a21355593b55eb49ff534d31f81c584",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/media/platform/ti/vpe/vip.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.0"
            },
            {
              "lessThan": "7.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.5",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ti: vpe: quiesce overflow recovery before freeing streams\n\nThe VIP overflow recovery worker is armed from the hardirq handler when a\nFIFO overflow is detected, and the list-complete path looks the stream up\nthrough the VPDMA list private pointer. Both keep touching stream, port\nand device state; the recovery worker also resets the parser and VPDMA,\nrepopulates the descriptor list, and re-enables the per-list IRQs.\n\nvip_stop_streaming() masks and clears the per-list IRQs, but it neither\nsynchronizes the hardirq handler nor disables recovery_work. An overflow\nIRQ that has already queued recovery_work, or a list-complete IRQ in\nflight when the stream is torn down, can therefore still dereference the\nstream after its resources are released: the descriptor list is freed by\nvip_release_stream() on file release, and the stream itself by\nfree_stream() on unbind/remove.\n\nDrain the recovery worker and the IRQ handler at both teardown points\nthrough a shared vip_quiesce_stream() helper, before any stream-owned\nresource is released. disable_work_sync() cancels pending recovery_work,\ndrains a running instance, and raises its disable depth, so a subsequent\nschedule_work() issued by a racing IRQ handler is rejected at the\nworkqueue scheduler: recovery_work cannot be requeued after\ndisable_work_sync() takes effect. The worker may still re-enable the\nper-list IRQs before disable_work_sync() returns; disable_irqs() then\nmasks those sources and synchronize_irq() waits for any in-flight handler\nthat still dereferences stream state. In vip_stop_streaming() the helper\nruns before the parser is stopped, since a worker drained by\ndisable_work_sync() may re-enable the parser before exiting and would\notherwise undo the stop. recovery_work is created disabled and enabled in\nvip_start_streaming() before IRQs, pairing the enable with the teardown\ndisable across the streaming lifecycle.\n\nThis issue was found by an in-house static analysis tool and confirmed\nby manual code review."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "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.\nAC: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.\nPR: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.\nUI: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.\nS: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.\nC: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.\nI: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.\nA: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."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T08:54:08.215Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/fd5b4a14c87b21e1c9eaee603b01bb7fa7db45c8"
        },
        {
          "url": "https://git.kernel.org/stable/c/aeaacc3001449d44b4ab7da56331121d1f3b137b"
        }
      ],
      "title": "media: ti: vpe: quiesce overflow recovery before freeing streams",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89875",
    "datePublished": "2026-09-16T10:31:42.777Z",
    "dateReserved": "2026-09-11T19:38:34.772Z",
    "dateUpdated": "2026-10-19T08:54:08.215Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…