Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: drain a slave&amp;#39;s callback before its master detaches it<br /> <br /> snd_timer_close_locked() drains the closing instance&amp;#39;s own in-flight<br /> callback (IFLG_CALLBACK) before freeing it, but not its slaves&amp;#39;. When a<br /> master instance is closed, remove_slave_links() clears each slave&amp;#39;s<br /> -&gt;timer; the slave&amp;#39;s own close then reads timer == NULL and takes the<br /> branch that skips the drain entirely (snd_timer_stop_slave() also no-ops<br /> on a NULL timer). So a slave whose callback is still running when the<br /> master is closed is freed underneath the live callback, leading to<br /> use-after-free.<br /> <br /> Drain the slaves too before remove_slave_links() severs them.<br /> snd_timer_stop() has already taken this instance off the active list, so<br /> no new slave callback can be queued. Take the slaves off the ack list so<br /> a pending one can&amp;#39;t fire either, then wait for any that is already in<br /> flight.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vivid: fix cleanup bugs in vivid_init()<br /> <br /> When platform_device_register() fails in vivid_init(), the embedded<br /> struct device in vivid_pdev has already been initialized by<br /> device_initialize(), but the failure path jumps to free_output_strings<br /> without dropping the device reference for the current platform device:<br /> <br /> vivid_init()<br /> -&gt; platform_device_register(&amp;vivid_pdev)<br /> -&gt; device_initialize(&amp;vivid_pdev.dev)<br /> -&gt; setup_pdev_dma_masks(&amp;vivid_pdev)<br /> -&gt; platform_device_add(&amp;vivid_pdev)<br /> <br /> This leads to a reference leak when platform_device_register() fails.<br /> Fix this by calling platform_device_put() before jumping to the common<br /> cleanup path.<br /> <br /> Also, the unreg_driver label incorrectly calls<br /> platform_driver_register() instead of platform_driver_unregister(),<br /> which breaks cleanup when workqueue creation fails after successful<br /> driver registration. Fix that as well.<br /> <br /> The reference leak was identified by a static analysis tool I developed<br /> and confirmed by manual review. The incorrect cleanup call was found<br /> during code inspection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: validate assoc response length before subtracting header<br /> <br /> wilc_parse_assoc_resp_info() computes the trailing IE length as<br /> <br /> ies_len = buffer_len - sizeof(*res);<br /> <br /> without first checking that buffer_len is at least sizeof(struct<br /> wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a<br /> received association response (host_int_parse_assoc_resp_info() passes<br /> hif_drv-&gt;assoc_resp / assoc_resp_info_len straight in) and must be<br /> validated before the driver accesses the fixed header.<br /> <br /> For a frame shorter than the 6-byte fixed header, the subtraction wraps.<br /> For a four-byte response the result is truncated to a u16 ies_len of<br /> 65534, so kmemdup() then attempts to copy 65534 bytes starting at<br /> buffer + sizeof(*res), beyond the valid association-response data<br /> (CWE-125). A response shorter than four bytes can also cause an<br /> out-of-bounds read of res-&gt;status_code at offsets 2 and 3.<br /> <br /> Reject frames too short to hold the fixed header before touching the<br /> header or computing ies_len. Also set the connection status to a failure<br /> on this path: the caller falls through to a<br /> "conn_info-&gt;status == WLAN_STATUS_SUCCESS" check after the parser<br /> returns, so leaving the status untouched could let a malformed short<br /> response be treated as a successful association.