Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: keep err zero after successful ovl_cache_get()<br /> <br /> ovl_iterate_merged() stores PTR_ERR(cache) in err before checking<br /> IS_ERR(cache). On success err holds the truncated cache pointer and<br /> can be returned as a bogus non-zero error.<br /> <br /> The syzbot reproducer reaches this through overlay-on-overlay readdir:<br /> <br /> getdents64<br /> iterate_dir(outer overlay file)<br /> ovl_iterate_merged()<br /> ovl_cache_get()<br /> ovl_dir_read_merged()<br /> ovl_dir_read()<br /> iterate_dir(inner overlay file)<br /> ovl_iterate_merged()<br /> <br /> Only compute PTR_ERR(cache) on the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: reject fuse_notify() pagecache ops on directories<br /> <br /> The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the<br /> FUSE daemon to actively write/read pagecache contents.<br /> <br /> For directories with FOPEN_CACHE_DIR, the pagecache is used as<br /> kernel-internal cache storage, and userspace is not supposed to have<br /> direct access to this cache - in particular, fuse_parse_cache() will hit<br /> WARN_ON() if the cache contains bogus data.<br /> <br /> Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than<br /> regular files with -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios<br /> <br /> FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios<br /> can contain uninitialized data.<br /> Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already<br /> in the page cache and not wait for data from the FUSE daemon, treat<br /> !uptodate folios as if they weren&amp;#39;t present.<br /> <br /> This only has security impact on systems that don&amp;#39;t enable automatic<br /> zero-initialization of all page allocations via<br /> CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.

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 /> misc: fastrpc: fix use-after-free race in fastrpc_map_create<br /> <br /> fastrpc_map_lookup returns a raw pointer after releasing fl-&gt;lock. The<br /> caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero)<br /> on this unprotected pointer. A concurrent MEM_UNMAP can free the map<br /> between the lock release and the kref operation, resulting in a<br /> use-after-free on the freed slab object.<br /> <br /> Restore the take_ref parameter to fastrpc_map_lookup so the reference<br /> is acquired atomically under fl-&gt;lock before the pointer is exposed to<br /> the caller.

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 /> 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.