Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper<br /> <br /> mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on<br /> bss_desc-&gt;bcn_ht_cap being present, but then dereferences a different<br /> pointer, bss_desc-&gt;bcn_ht_oper:<br /> <br /> if (ISSUPP_CHANWIDTH40(priv-&gt;adapter-&gt;hw_dot_11n_dev_cap) &amp;&amp;<br /> bss_desc-&gt;bcn_ht_cap &amp;&amp;<br /> ISALLOWED_CHANWIDTH40(bss_desc-&gt;bcn_ht_oper-&gt;ht_param))<br /> <br /> bcn_ht_cap and bcn_ht_oper are populated independently while parsing the<br /> associated AP&amp;#39;s beacon in mwifiex_update_bss_desc_with_ie(): an AP that<br /> advertises an HT Capabilities element but no HT Operation element leaves<br /> bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a<br /> peer while associated to such an AP then dereferences the NULL<br /> bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the<br /> driver NULL-checks it first.<br /> <br /> Guard on the pointer that is actually dereferenced.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: fix OOB access from firmware ADDBA window size<br /> <br /> aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied<br /> win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not<br /> return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to<br /> compute a kzalloc size and stored in rxtid-&gt;hold_q_sz, leading to<br /> zero-size or overflowed allocations and subsequent out-of-bounds access.<br /> <br /> Clean up any previously active aggregation session for the TID first,<br /> then return early when win_sz is out of the valid range, instead of<br /> proceeding with a broken allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: close a re-opened queue timer in the destructor<br /> <br /> queue_delete() closes the queue timer, then frees it. snd_seq_timer_close()<br /> clears q-&gt;timer-&gt;timeri. snd_use_lock_sync() then drains borrowers, and<br /> snd_seq_timer_delete() frees q-&gt;timer.<br /> <br /> A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT<br /> that took a queueptr() use_lock reference before the queue was unlinked<br /> runs snd_seq_timer_open() after the close. Open refuses re-open only while<br /> timeri is set, and the close just cleared it, so it re-opens timeri.<br /> <br /> snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop()<br /> is a no-op, because running was cleared first. So it frees q-&gt;timer with the<br /> instance still live. The queue is freed next.<br /> <br /> The instance stays on the global timer with callback_data pointing at the<br /> freed queue. A non-owner START on the unlocked queue arms it. The next tick<br /> derefs the freed queue in snd_seq_timer_interrupt().<br /> <br /> Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and<br /> no queue ownership required.<br /> <br /> Close any lingering instance in the destructor. There, -&gt;timeri can no<br /> longer change: the queue is unlinked and all use_lock borrowers have<br /> drained, so no snd_seq_queue_use() can re-open it. Close it before clearing<br /> q-&gt;timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt()<br /> to finish, and that callback still reads q-&gt;timer (via snd_seq_check_queue()),<br /> so q-&gt;timer must stay valid until it drains.