Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: msi2500: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> msi2500_start_streaming() had five error paths that all hit this trap<br /> and were further tangled by ret-overwriting between calls:<br /> <br /> - -ENODEV when the USB device was already disconnected<br /> - -ERESTARTSYS when mutex_lock_interruptible() was interrupted<br /> - msi2500_set_usb_adc() failure: ret was silently overwritten by<br /> the next call (msi2500_isoc_init), so the error was lost entirely<br /> - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but<br /> the function then fell through to msi2500_ctrl_msg() and again<br /> masked the original error by overwriting ret<br /> - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,<br /> leaving isoc URBs submitted with no way for the driver to consume<br /> them<br /> <br /> Consolidate the error paths into a small goto chain. Every failure<br /> now stops the function, drains the queued-buffer list, and returns<br /> the real error code. The ctrl_msg failure path also rolls back the<br /> preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before<br /> unlocking and draining.<br /> <br /> The cleanup helper takes a vb2_buffer_state argument so that the<br /> start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as<br /> expected by userspace on start_streaming failure) while stop_streaming<br /> keeps its existing VB2_BUF_STATE_ERROR semantics.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: meson: vdec: Fix memory leak in error path of vdec_open<br /> <br /> The vdec_open() function previously jumped directly to<br /> err_m2m_release when vdec_init_ctrls() failed, skipping<br /> release of the m2m context. This caused a resource leak.<br /> <br /> Fix it by introducing a proper err_m2m_ctx_release label<br /> that calls v4l2_m2m_ctx_release(sess-&gt;m2m_ctx) before<br /> releasing the m2m device.<br /> <br /> This was identified via kmemleak:<br /> unreferenced object 0xffff0000205d6878 (size 8):<br /> comm "v4l_id", pid 5289, jiffies 4294938580<br /> hex dump (first 8 bytes):<br /> 40 d2 49 18 00 00 ff ff @.I.....<br /> backtrace (crc d3204599):<br /> kmemleak_alloc+0xc8/0xf0<br /> __kvmalloc_node_noprof+0x60c/0x850<br /> v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]<br /> vdec_open+0x1f4/0x788 [meson_vdec]<br /> v4l2_open+0x144/0x460 [videodev]<br /> chrdev_open+0x1ac/0x500<br /> do_dentry_open+0x3f0/0xfe8<br /> vfs_open+0x68/0x320<br /> do_open+0x2d8/0x9a8<br /> path_openat+0x1d0/0x4f0<br /> do_filp_open+0x190/0x380<br /> do_sys_openat2+0xf8/0x1b0<br /> __arm64_sys_openat+0x13c/0x1e8<br /> invoke_syscall+0xdc/0x268<br /> el0_svc_common.constprop.0+0x178/0x258<br /> do_el0_svc+0x4c/0x70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx23885: add ioremap return check and cleanup<br /> <br /> Add a check for the return value of pci_ioremap_bar()<br /> in cx23885_dev_setup().<br /> If ioremap for BAR0 fails, release the already allocated<br /> PCI memory region,<br /> decrement the device count, and return -ENODEV.<br /> <br /> This prevents a potential null pointer dereference and<br /> ensures proper cleanup<br /> on memory mapping failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx231xx: fix devres lifetime<br /> <br /> USB drivers bind to USB interfaces and any device managed resources<br /> should have their lifetime tied to the interface rather than parent USB<br /> device. This avoids issues like memory leaks when drivers are unbound<br /> without their devices being physically disconnected (e.g. on probe<br /> deferral or configuration changes).<br /> <br /> Fix the driver state lifetime so that it is released on driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix potential out-of-bounds issues<br /> <br /> The maximum downscaling factor supported by ISI can be up to 16. Add<br /> minimum value constraint before applying the setting to hardware.<br /> Otherwise, the process will not respond even when Ctrl+C is executed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: saa7134: Fix a possible memory leak in saa7134_video_init1<br /> <br /> In saa7134_video_init1(), the return value of the first<br /> saa7134_pgtable_alloc() is not checked. If it fails, the function<br /> continues as if successful, leaving the driver with an invalid page<br /> table. Additionally, if vb2_queue_init() for the VBI queue fails after<br /> the video queue page table has been allocated, the allocated memory is<br /> not freed before returning. The second saa7134_pgtable_alloc() also<br /> lacks a return value check. Errors occur during device probing before<br /> the device is fully registered, the normal cleanup path in<br /> saa7134_finidev() is not executed, leading to memory leaks and<br /> potential use of uninitialized DMA resources.<br /> <br /> Check the return value of both saa7134_pgtable_alloc() calls and<br /> propagate errors. On failure of any later step, free allocated page<br /> tables to avoid memory leaks. Ensure control handlers are also<br /> released on error to prevent further resource leakage.<br /> <br /> Found by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rtl2832_sdr: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> rtl2832_sdr_start_streaming() had multiple error paths that hit this<br /> trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six<br /> `goto err` paths covering subdev s_power, tuner setup, ADC setup,<br /> stream-buffer allocation, urb allocation, and urb submission failures.<br /> None of them returned the queued buffers.<br /> <br /> The original function had no distinct success exit and fell straight<br /> through into the err label, which previously only did mutex_unlock and<br /> "return ret". Adding queued-buffer cleanup at err must therefore be<br /> paired with an explicit success return; otherwise every successful<br /> start would also drain the buffer queue and kill streaming. Add that<br /> success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err<br /> label and before each early return.<br /> <br /> The cleanup helper takes a vb2_buffer_state argument so that the<br /> start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as<br /> expected by userspace on start_streaming failure) while stop_streaming<br /> keeps its existing VB2_BUF_STATE_ERROR semantics.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").<br /> <br /> The err label still does not roll back power_ctrl(), frontend_ctrl(),<br /> the POWER_ON flag, or stream/URB allocations that may have happened<br /> before the failing step. Those are pre-existing leaks of a different<br /> class and are not addressed here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rtl2832: fix use-after-free in rtl2832_remove()<br /> <br /> cancel_delayed_work_sync() is called before i2c_mux_del_adapters()<br /> in rtl2832_remove(). While the cancel waits for any running instance<br /> of i2c_gate_work to finish, it does not prevent the timer from being<br /> rescheduled by a concurrent thread.<br /> <br /> During probe, the r820t_attach() call attempts I2C transfers through<br /> the mux adapter. These transfers go through i2c_mux_master_xfer(),<br /> which calls rtl2832_deselect() after the transfer completes,<br /> rescheduling i2c_gate_work via schedule_delayed_work(). If this<br /> transfer is still in flight when rtl2832_remove() runs,<br /> rtl2832_deselect() can reschedule i2c_gate_work after it has been<br /> cancelled, causing a use-after-free when kfree(dev) is called.<br /> <br /> Fix this by calling i2c_mux_del_adapters() before<br /> cancel_delayed_work_sync(). Once the mux adapter is unregistered, no<br /> new I2C transfers can go through it, so rtl2832_deselect() can no<br /> longer reschedule i2c_gate_work. The subsequent<br /> cancel_delayed_work_sync() is then guaranteed to be final.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: radio-si476x: Unregister v4l2_device on probe failure<br /> <br /> si476x_radio_probe() registers radio-&gt;v4l2dev before allocating the V4L2<br /> controls and before registering the video device. If any of those later<br /> steps fails, probe returns through the exit label after freeing only the<br /> control handler.<br /> <br /> A failed probe does not call si476x_radio_remove(), so the<br /> v4l2_device_unregister() there is not reached. This leaves the parent<br /> device reference taken by v4l2_device_register() behind on the error path.<br /> <br /> Unregister the V4L2 device in the probe error path after freeing the<br /> controls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pwc: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> pwc&amp;#39;s start_streaming() had two early returns that hit this trap:<br /> -ENODEV when the USB device was already disconnected, and -ERESTARTSYS<br /> when mutex_lock_interruptible() was interrupted by a signal. Call the<br /> existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED<br /> before returning (matching the state already used by the<br /> pwc_isoc_init() error path in the same function).<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: dm1105: Free allocated workqueue<br /> <br /> Destroy allocated workqueue in remove() callback to free its resources,<br /> thus fixing memory leak.