CVE-2026-68217

media: pwc: Drain fill_buf on start_streaming() failure

N/A
Published: August 10, 2026 at 12:00 PM UTC
Updated: August 19, 2026 at 05:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 ("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.1 ≤ v < 5.10.2653.1 ≤ v < 5.15.2163.1 ≤ v < 6.1.1833.1 ≤ v < 6.12.1013.1 ≤ v < 6.18.423.1 ≤ v < 6.6.1483.1 ≤ v < 7.1.63.1 ≤ v < 7.23.1885fe18f5542fe283a17f70583383c6cadcba1c3
Vendor states this is fixed in 5d4812668b03f823b5044789d6aa77fe56b42587 (fixed)
Vendor states this is fixed in 906e410dcffbbd99fb4081abab817a830033aa28 (fixed)
Vendor states this is fixed in 97f3c15957ec7e6d249f05407ad947c0644df24d (fixed)
Vendor states this is fixed in 9afd605dcd96c7a45f338eded1de16679b30e1df (fixed)
Vendor states this is fixed in a4afffd148991a826e8995362fb10cf8705c1130 (fixed)
Vendor states this is fixed in a56e7641e09bd80b976e944ae759109b86fd5b38 (fixed)
Vendor states this is fixed in acc789b2173070638cad89c2b61d33ed338be0dd (fixed)
Vendor states this is fixed in eabe9a59640698137d7382d5b549e95dc37f7565 (fixed)
Vendor states this is fixed in 3.1 (unaffected)
Vendor states this is fixed in 5.10.265 (unaffected)
Vendor states this is fixed in 5.15.216 (unaffected)
Vendor states this is fixed in 6.1.183 (unaffected)
Vendor states this is fixed in 6.12.101 (unaffected)
Vendor states this is fixed in 6.18.42 (unaffected)
Vendor states this is fixed in 6.6.148 (unaffected)
Vendor states this is fixed in 7.1.6 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card