Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()<br /> <br /> The v4l2 helper v4l2_async_register_subdev_sensor() calls<br /> v4l2_async_register_subdev(), which is a macro that expands to<br /> __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded<br /> inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module<br /> rather than the sensor driver module that originally set sd-&gt;owner. When<br /> v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then<br /> overwrites the sensor driver&amp;#39;s owner with NULL.<br /> <br /> This causes the problem that the sensor module&amp;#39;s reference count is never<br /> incremented during async registration, so the module can be removed while<br /> the subdevice is still in use by a notifier (e.g., a CSI-2 receiver<br /> bridge driver).<br /> <br /> Fix this by renaming v4l2_async_register_subdev_sensor() to<br /> __v4l2_async_register_subdev_sensor() with an added explicit module<br /> argument and introducing a wrapper macro:<br /> #define v4l2_async_register_subdev_sensor(sd) \<br /> __v4l2_async_register_subdev_sensor(sd, THIS_MODULE)<br /> <br /> This ensures the sensor driver module is properly referenced even when<br /> the sensor driver does not init the owner field before calling<br /> v4l2_async_register_subdev_sensor() and prevents premature module removal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice()<br /> <br /> In vip_probe_slice(), the error check for devm_kzalloc() incorrectly<br /> uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer.<br /> <br /> Return -ENOMEM for devm_kzalloc() failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: stm32-dcmipp: 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 /> dcmipp_bytecap_start_streaming() returned -EINVAL when the source<br /> subdevice could not be resolved from the media graph, before<br /> pm_runtime_resume_and_get() and media_pipeline_start() had been called.<br /> The remaining error paths already converge on the err_buffer_done<br /> label, which calls dcmipp_bytecap_all_buffers_done(...,<br /> VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate<br /> err_pm_put / err_media_pipeline_stop labels are skipped, which is<br /> correct because nothing they would undo has happened yet.<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: vivid: check for vb2_is_busy() when toggling caps<br /> <br /> The vivid_update_format_cap/out() functions must only be called if the<br /> capture/output queue are not busy. But for the controls that select<br /> the CROP/COMPOSE/SCALE capability that is not checked.<br /> <br /> Only when streaming starts will they be set to &amp;#39;grabbed&amp;#39; and it is<br /> impossible to change the control, but between REQBUFS and STREAMON you<br /> are still allowed to set these controls. Since vivid_update_format_cap/out<br /> will change the format, this can cause unexpected results.<br /> <br /> Besides adding these checks, also add a WARN_ON in<br /> vivid_update_format_cap/out() if the queue is busy.<br /> <br /> I&amp;#39;m 90% certain that this is the cause of this syzbot bug:<br /> <br /> https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89<br /> <br /> But since we never have reproducers, it is hard to be certain. In any case,<br /> these checks are needed regardless.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-ctrls: validate HEVC active reference counts<br /> <br /> HEVC slice parameters are shared stateless V4L2 controls, but the common<br /> validation path does not verify the active L0/L1 reference counts before<br /> driver-specific code consumes them.<br /> <br /> The original report came from Cedrus, but the active count bounds are<br /> not Cedrus-specific. Validate them in the common HEVC slice control path<br /> so stateless HEVC drivers get the same basic guarantees as soon as the<br /> control is queued.<br /> <br /> Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may<br /> use out-of-range sentinel values such as 0xff for missing references, and<br /> some hardware can use that information for concealment. Keep this common<br /> check limited to the active reference counts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ti: vpe: unwind v4l2 device registration on probe error<br /> <br /> If the vpe_top resource is missing, vpe_probe() returns -ENODEV after<br /> v4l2_device_register() has succeeded. Probe failures do not call the<br /> driver&amp;#39;s remove callback, so the v4l2 device remains registered on that<br /> error path.<br /> <br /> Route that failure through the existing v4l2_device_unregister() unwind<br /> label, matching the other errors after v4l2_device_register().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: sun4i-csi: 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 /> sun4i_csi_start_streaming() returned -EINVAL when no matching CSI<br /> format could be found, before any setup (scratch buffer allocation,<br /> pipeline start) had been performed. The remaining error paths already<br /> converge on the err_clear_dma_queue label, which calls<br /> return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi-&gt;qlock. Jump<br /> to that label directly: the intermediate err_disable_device /<br /> err_disable_pipeline / err_free_scratch_buffer labels are skipped,<br /> which is correct because nothing they would undo has happened yet.<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: stm32: dcmi: unregister notifier on probe failure<br /> <br /> dcmi_graph_init() registers the async notifier before dcmi_probe() toggles<br /> the reset line. If reset_control_assert() or reset_control_deassert()<br /> fails afterwards, probe returns through err_cleanup and the driver core<br /> will not call dcmi_remove().<br /> <br /> Unregister the notifier before cleaning it up on that error path,<br /> matching the successful remove path and the V4L2 async notifier lifetime<br /> rules.<br /> <br /> [hverkuil: added Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: fix use-after-free in aggr_reset_state()<br /> <br /> The aggr_reset_state() function uses timer_delete() (non-synchronous)<br /> for the aggregation timer before proceeding to delete TID state and<br /> before the structure is freed by callers like aggr_module_destroy().<br /> <br /> If the timer callback (aggr_timeout) is executing when aggr_reset_state()<br /> is called, the callback will continue to access aggr_conn fields like<br /> rx_tid[] and stat[] which may be freed immediately after by<br /> kfree(aggr_info-&gt;aggr_conn) in aggr_module_destroy().<br /> <br /> Additionally, the timer callback can re-arm itself via mod_timer() while<br /> aggr_reset_state() is running, creating a more complex race condition.<br /> <br /> Use timer_delete_sync() instead to ensure any running timer callback<br /> has completed before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: don&amp;#39;t re-enter an instance callback that is still running<br /> <br /> The userspace-driven timer (utimer) TRIGGER ioctl calls<br /> snd_timer_interrupt() directly with no serialization, so two threads<br /> triggering the same utimer can run snd_timer_interrupt() on one<br /> snd_timer concurrently.<br /> <br /> snd_timer_process_callbacks() drops timer-&gt;lock around each instance<br /> callback and marks the in-flight callback with the single<br /> SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that<br /> bit to drain an in-flight callback before freeing the instance. The bit<br /> cannot represent two concurrent callbacks: when a second interrupt<br /> re-queues an instance whose callback is still running, both run at once,<br /> the first to finish clears the bit, and the close-path drain then frees<br /> the instance (and its callback_data) while the other callback is still<br /> live - a use-after-free reachable by any user able to open<br /> /dev/snd/timer, both via a user timer instance and via a sequencer queue<br /> timer bound to the utimer.<br /> <br /> snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer-&gt;lock, so<br /> a concurrent interrupt already observes it under the lock. Skip<br /> re-queuing an instance (and its slaves) to the ack/sack list while its<br /> callback is in flight; the accumulated pticks are delivered on the next<br /> tick, so no event is lost.