Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one<br /> <br /> Sashiko notes:<br /> <br /> &gt; regarding the bounds check in snp_filter_reserved_mem_regions()<br /> &gt; called via walk_iomem_res_desc(): does the check<br /> &gt; if ((range_list-&gt;num_elements * 16 + 8) &gt; PAGE_SIZE)<br /> &gt; allow an off-by-one heap buffer overflow?<br /> &gt;<br /> &gt; If range_list-&gt;num_elements is 255, 255 * 16 + 8 = 4088, which is Writing range-&gt;base (8 bytes) fills 4088-4095, but writing range-&gt;page_count<br /> &gt; (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated<br /> &gt; PAGE_SIZE buffer.<br /> <br /> Fix this by accounting for the entry about to be written to, in addition to<br /> the entries that are already allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> OPP: Fix race between OPP addition and lookup<br /> <br /> A race exists between dev_pm_opp_add_dynamic() and<br /> dev_pm_opp_find_freq_exact():<br /> <br /> CPU0 (add) CPU1 (lookup)<br /> ------------------------------- ------------------------------<br /> _opp_add()<br /> mutex_lock()<br /> list_add(&amp;new_opp-&gt;node, head)<br /> mutex_unlock() _opp_table_find_key()<br /> mutex_lock()<br /> dev_pm_opp_get(opp)<br /> kref_get()<br /> mutex_unlock()<br /> kref_init(&amp;new_opp-&gt;kref)<br /> dev_pm_opp_put()<br /> kref_put_mutex()<br /> <br /> The newly added OPP is inserted into the list before its kref is<br /> initialized. A concurrent lookup can find this OPP and increment its<br /> reference count while it is still uninitialized, leading to refcount<br /> corruption and a potential premature free.<br /> <br /> Fix this by initializing -&gt;kref and -&gt;opp_table before making the OPP<br /> visible via list_add(). This ensures any concurrent lookup observes a<br /> fully initialized object.<br /> <br /> [ Viresh: Updated commit log ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().<br /> <br /> udp_tunnel_sock_release() could set sk-&gt;sk_user_data to NULL<br /> while vxlan_gro_prepare_receive() is running.<br /> <br /> Let&amp;#39;s check if rcu_dereference_sk_user_data() is NULL after<br /> skb_gro_remcsum_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: cancel SSR work items during PCI shutdown<br /> <br /> A reboot can crash the kernel if it overlaps with WLAN firmware crash<br /> recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown<br /> path while freeing DMA-backed MHI contexts.<br /> <br /> Simplified trace:<br /> dma_free_attrs<br /> mhi_deinit_dev_ctxt [mhi]<br /> ath11k_pci_power_down [ath11k_pci]<br /> ath11k_pci_shutdown [ath11k_pci]<br /> device_shutdown<br /> kernel_restart<br /> <br /> On the host side, SSR is driven by the MHI RDDM callback, which queues<br /> reset_work to perform device recovery. reset_work power-cycles the device<br /> by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The<br /> power-down phase deinitializes MHI and frees DMA resources.<br /> <br /> Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR<br /> recovery flow. As a result, the shutdown path<br /> (ath11k_pci_shutdown() -&gt; ath11k_pci_power_down()) can race with the SSR<br /> recovery sequence.<br /> <br /> Fix this by canceling SSR-related work items during PCI shutdown, marking<br /> the device as unregistering, and serializing the RDDM callback path that<br /> checks and queues reset_work. This ensures that no new SSR recovery work<br /> can be queued once teardown has started, and that any in-flight recovery<br /> work is fully synchronized before device power-down, preventing MHI<br /> teardown and DMA resource freeing from running more than once.<br /> <br /> Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k<br /> devices do not queue reset_work in normal SSR flows.<br /> <br /> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: fix OOB access from firmware tx status queue ID<br /> <br /> ath_tx_edma_tasklet() accesses sc-&gt;tx.txq[ts.qid] where ts.qid is a<br /> 4-bit hardware field (0-15), but the txq array only has<br /> ATH9K_NUM_TX_QUEUES (10) entries. A qid &gt;= 10 causes an OOB array<br /> access.<br /> <br /> Add a bounds check on ts.qid before using it as an array index.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: add bounds check on firmware mac_id in link lookup<br /> <br /> The mac_id field in RX descriptors is 8 bits wide (0-255), but<br /> assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries.<br /> While the driver currently assigns mac_id values below 128, the<br /> descriptor value comes from firmware and is not validated before use<br /> as an array index. Add a defensive bounds check in<br /> rtw89_assoc_link_rcu_dereference() to guard against out-of-range<br /> firmware values.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Bound synthetic-field strings with seq_buf<br /> <br /> The synthetic field helpers build a prefixed synthetic variable name and<br /> a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The<br /> current code appends those strings with raw strcat(), so long key lists,<br /> field names, or saved filters can run past the end of the staging<br /> buffers.<br /> <br /> Build both strings with seq_buf and propagate -E2BIG if either the<br /> synthetic variable name or the generated command exceeds<br /> MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while<br /> using the helper intended for bounded command construction.<br /> <br /> [ sdr: Moved struct seq_buf *s for upside-down x-mas tree formatting ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: limit target bio polling to one shot<br /> <br /> dm_poll_bio() is the -&gt;poll_bio() callback for a stacked dm device.<br /> The caller only knows about the dm queue, so it may decide to do a<br /> spinning poll if it thinks a single queue is being polled. Passing those<br /> flags unchanged to the mapped clone lets blk_mq_poll() spin on a target<br /> queue from inside dm_poll_bio().<br /> <br /> With io_uring IOPOLL on a dm-stripe target this can keep a task in<br /> <br /> dm_poll_bio() -&gt; bio_poll() -&gt; blk_mq_poll()<br /> <br /> long enough to trigger an RCU CPU stall, before io_uring gets back to<br /> io_iopoll_check() and its need_resched() check.<br /> <br /> Keep dm&amp;#39;s -&gt;poll_bio() bounded by forcing one-shot polling for target<br /> bios. The caller can invoke dm_poll_bio() again if it wants to keep<br /> polling, and it also gets a chance to reap completions or reschedule<br /> between passes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/syncobj: Fix memory leak in drm_syncobj_find_fence()<br /> <br /> Commit 18226ba52159 ("drm/syncobj: reject invalid flags in<br /> drm_syncobj_find_fence") forgot to take into account the fact that<br /> drm_syncobj_find() takes a reference to syncobj and returns early<br /> without dropping the reference, leading to memory leaks.<br /> <br /> Reported by: Sam Spencer

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: fix integer overflow in immediate data length check<br /> <br /> imm_buf-&gt;len is a user-controlled uint32_t received from the network.<br /> Adding it to imm_data_offset without overflow checking allows a<br /> malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap<br /> around to a small value, bypassing the bounds check, and subsequently<br /> passing a ~4GB length to sg_init_one().<br /> <br /> Use check_add_overflow() to detect wrapping before the comparison.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference<br /> <br /> MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list<br /> before initializing the fields used by the shared error path.<br /> <br /> If eventfd_ctx_fdget() then fails, the unwind path dereferences<br /> event_sub-&gt;ev_file in uverbs_uobject_put() and calls<br /> subscribe_event_xa_dealloc() with an unset xa_key_level1.<br /> <br /> subscribe_event_xa_alloc() creates the XA entry exactly once for a given<br /> key_level1, on the first occurrence of that key. The unwind path must<br /> therefore call subscribe_event_xa_dealloc() exactly once for it as well.<br /> <br /> Enforce that by adding devx_key_in_sub_list() and calling<br /> subscribe_event_xa_dealloc() only when the last matching pending entry is<br /> being cleaned up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure<br /> <br /> mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with<br /> mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path<br /> through mlx5r_umr_unmap_free_xlt().<br /> <br /> After mlx5_odp_populate_xlt() became fallible, its error path returned<br /> directly and skipped that cleanup. This leaks the XLT DMA mapping and<br /> buffer. If the emergency XLT page was used, it also leaves<br /> xlt_emergency_page_mutex locked.<br /> <br /> Break out of the loop so execution falls through the existing cleanup path.