Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context<br /> <br /> There is a race between fastrpc_device_release() and the workqueue<br /> that processes DSP responses. When the user closes the file descriptor,<br /> fastrpc_device_release() frees the fastrpc_user structure. Concurrently,<br /> an in-flight DSP invocation can complete and fastrpc_rpmsg_callback()<br /> schedules context cleanup via schedule_work(&amp;ctx-&gt;put_work). If the<br /> workqueue runs fastrpc_context_free() in parallel with or after<br /> fastrpc_device_release() has freed the user structure, it dereferences<br /> the freed fastrpc_user. Depending on the state of the context at the<br /> time of the race, any one of the following accesses can be hit:<br /> <br /> 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf-&gt;fl-&gt;cctx, ...)<br /> to strip the SID bits from the stored IOVA before passing the<br /> physical address to dma_free_coherent().<br /> <br /> 2. fastrpc_free_map() reads map-&gt;fl-&gt;cctx-&gt;vmperms[0].vmid to<br /> reconstruct the source permission bitmask needed for the<br /> qcom_scm_assign_mem() call that returns memory from the DSP VM<br /> back to HLOS.<br /> <br /> 3. fastrpc_free_map() acquires map-&gt;fl-&gt;lock to safely remove the<br /> map node from the fl-&gt;maps list.<br /> <br /> The resulting use-after-free manifests as:<br /> <br /> pc : fastrpc_buf_free+0x38/0x80 [fastrpc]<br /> lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc]<br /> fastrpc_context_free+0xa8/0x1b0 [fastrpc]<br /> fastrpc_context_put_wq+0x78/0xa0 [fastrpc]<br /> process_one_work+0x180/0x450<br /> worker_thread+0x26c/0x388<br /> <br /> Add kref-based reference counting to fastrpc_user. Have each invoke<br /> context take a reference on the user at allocation time and release it<br /> when the context is freed. Release the initial reference in<br /> fastrpc_device_release() at file close. Move the teardown of the user<br /> structure — freeing pending contexts, maps, mmaps, and the channel<br /> context reference — into the kref release callback fastrpc_user_free(),<br /> so that it runs only when the last reference is dropped, regardless of<br /> whether that happens at device close or after the final in-flight<br /> context completes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memcg: use round-robin victim selection in refill_stock<br /> <br /> Harry Yoo reported that get_random_u32_below() is not safe to call in the<br /> nmi context and memcg charge draining can happen in nmi context.<br /> <br /> More specifically get_random_u32_below() is neither reentrant- nor<br /> NMI-safe: it acquires a per-cpu local_lock via local_lock_irqsave() on the<br /> batched_entropy_u32 state. An NMI that lands on a CPU mid-update of the<br /> ChaCha batch state and recurses into the random subsystem would corrupt<br /> that state. The memcg_stock local_trylock prevents re-entry on the percpu<br /> stock itself, but cannot protect an unrelated subsystem&amp;#39;s per-cpu lock.<br /> <br /> Replace the random pick with a per-cpu round-robin counter stored in<br /> memcg_stock_pcp and serialized by the same local_trylock that already<br /> guards cached[] and nr_pages[]. No atomics, no random calls, no extra<br /> locks needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: avoid potential null folio-&gt;mapping deref during error reporting<br /> <br /> When a buffered read fails, iomap_finish_folio_read() reports the error<br /> with fserror_report_io(folio-&gt;mapping-&gt;host, ...). This is called after<br /> ifs-&gt;read_bytes_pending has been decremented by the bytes attempted to<br /> be read.<br /> <br /> For a folio split across multiple read completions, the folio is only<br /> guaranteed to stay locked while read_bytes_pending &gt; 0. Once<br /> iomap_finish_folio_read() decrements read_bytes_pending, another<br /> in-flight read can complete and end the read on the folio, which unlocks<br /> it. This allows truncate logic to run and detach the folio (set<br /> folio-&gt;mapping to NULL). The error reporting path then can dereference a<br /> NULL folio-&gt;mapping. As reported by Sam Sun, this is the race that can<br /> occur:<br /> <br /> CPU0: failed completion CPU1: final completion CPU2: truncate<br /> ----------------------- ---------------------- --------------<br /> read_bytes_pending -= len<br /> finished = false<br /> /* preempted before<br /> fserror_report_io() */<br /> read_bytes_pending -= len<br /> finished = true<br /> folio_end_read()<br /> truncate clears<br /> folio-&gt;mapping<br /> fserror_report_io(<br /> folio-&gt;mapping-&gt;host, ...)<br /> ^ NULL deref<br /> <br /> Fix this by reporting the error first before decrementing<br /> ifs-&gt;read_bytes_pending.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/dma: Do not try to iommu_map a 0 length region in swiotlb<br /> <br /> iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three<br /> parts, the head, middle and trailer. If the middle is empty because there<br /> are no aligned pages it will call down to iommu_map() with a 0 size<br /> which the iommupt implementation will fail as illegal.<br /> <br /> It then tries to do an error unwind and starts from the wrong spot<br /> corrupting the mapping so the eventual destruction triggers a WARN_ON.<br /> <br /> Check for 0 length and avoid mapping and use offset not 0 as the starting<br /> point to unlink.<br /> <br /> This is frequently triggered by using some kinds of thunderbolt NVMe<br /> drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to<br /> pass in oddly aligned buffers for the passthrough commands from smartctl<br /> that hit this condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/rtmutex: Skip remove_waiter() when waiter is not enqueued<br /> <br /> syzbot triggered the following splat in remove_waiter() via<br /> FUTEX_CMP_REQUEUE_PI:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f]<br /> class_raw_spinlock_constructor<br /> remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561<br /> rt_mutex_start_proxy_lock+0x103/0x120<br /> futex_requeue+0x10e4/0x20d0<br /> __x64_sys_futex+0x34f/0x4d0<br /> <br /> task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection,<br /> leaving waiter-&gt;task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead<br /> of current in remove_waiter()") made this fatal.<br /> <br /> Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter()<br /> upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock<br /> return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock()<br /> (where &amp;#39;ret&amp;#39; was only ever 0 or

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix NULL pointer dereference in rpmsg callback<br /> <br /> A NULL pointer dereference was observed on Hawi at boot when the DSP<br /> sends a glink message before fastrpc_rpmsg_probe() has completed<br /> initialization:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178<br /> pc : _raw_spin_lock_irqsave+0x34/0x8c<br /> lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> ...<br /> Call trace:<br /> _raw_spin_lock_irqsave+0x34/0x8c (P)<br /> fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> qcom_glink_native_rx+0x538/0x6a4<br /> qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem]<br /> <br /> The faulting address 0x178 corresponds to the lock variable inside<br /> struct fastrpc_channel_ctx, confirming that cctx is NULL when<br /> fastrpc_rpmsg_callback() attempts to take the spinlock.<br /> <br /> There are two issues here. First, dev_set_drvdata() is called before<br /> spin_lock_init() and idr_init(), leaving a window where the callback<br /> can retrieve a valid cctx pointer but operate on an uninitialized<br /> spinlock. Second, the rpmsg channel becomes live as soon as the driver<br /> is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata()<br /> is called at all, resulting in dev_get_drvdata() returning NULL.<br /> <br /> Fix both issues by moving all cctx initialization ahead of<br /> dev_set_drvdata() so the structure is fully initialized before it<br /> becomes visible to the callback, and add a NULL check in<br /> fastrpc_rpmsg_callback() as a guard against any remaining window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phonet: free phonet_device after RCU grace period<br /> <br /> phonet_device_destroy() removes a phonet_device from the per-net device<br /> list with list_del_rcu(), but frees it immediately. RCU readers walking<br /> the same list can still hold a pointer to the object after it has been<br /> removed, leading to a slab-use-after-free.<br /> <br /> Use kfree_rcu(), matching the lifetime rule already used by<br /> phonet_address_del() for the same object type.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix DMA address corruption due to find_vma misuse<br /> <br /> fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided<br /> pointer and compute a DMA address offset. When the address falls in a gap<br /> before the returned VMA, (ptr &amp; PAGE_MASK) - vma-&gt;vm_start underflows,<br /> corrupting the DMA address sent to the DSP.<br /> <br /> Replace find_vma() with vma_lookup(), which returns NULL when the address<br /> is not contained within any VMA.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: core: fix use-after-free bugs in error paths<br /> <br /> Fix several instances of error paths in which we call<br /> __nvmem_device_put() - which may end up freeing the underlying memory<br /> and other resources - and then keep on using the nvmem structure. Always<br /> put the reference to the nvmem device as the last step before returning<br /> the error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: dw_mmc-rockchip: Add missing private data for very old controllers<br /> <br /> The really old controllers (rk2928, rk3066, rk3188) do not support UHS<br /> speeds at all, and thus never handled phase data.<br /> <br /> For that reason it never had a parse_dt callback and no driver private<br /> data at all.<br /> <br /> Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating<br /> support") makes the private data sort of mandatory, because the init<br /> function checks whether phases are configured internally or through the<br /> clock controller.<br /> <br /> This results in the old SoCs then experiencing NULL-pointer dereferences<br /> when they try to access that private-data struct.<br /> <br /> While we could have if (priv) conditionals in all places, it&amp;#39;s way less<br /> cluttery to just give the old types their private-data struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix the ACK parser to extract the SACK table for parsing<br /> <br /> Fix modification of the received skbuff in rxrpc_input_soft_acks() and a<br /> potential incorrect access of the buffer in a fragmented UDP packet (the<br /> packet would probably have to be deliberately pre-generated as fragmented)<br /> when AF_RXRPC tries to extract the contents of the SACK table by copying<br /> out the contents of the SACK table into a buffer before attempting to parse<br /> <br /> AF_RXRPC assumes that it can just call skb_condense() and then validly<br /> access the SACK table from skb-&gt;data and that it will be a flat buffer -<br /> but skb_condense() can silently fail to do anything under some<br /> circumstances.<br /> <br /> Note that whilst rxrpc_input_soft_acks() should be able to parse extended<br /> ACKs, the rest of AF_RXRPC doesn&amp;#39;t currently support that.<br /> <br /> Further, there&amp;#39;s then no need to call skb_condense() in rxrpc_input_ack(),<br /> so don&amp;#39;t.