Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: reject NPU_OP_RESIZE commands from userspace<br /> <br /> NPU_OP_RESIZE is a U85-only command that the driver does not yet<br /> implement. The existing WARN_ON(1) placeholder fires unconditionally<br /> whenever userspace submits this command via DRM_IOCTL_ETHOSU_GEM_CREATE,<br /> causing unbounded kernel log spam.<br /> <br /> If panic_on_warn is set the kernel panics, giving any unprivileged user<br /> with access to the DRM device a trivial denial-of-service primitive.<br /> <br /> Replace the WARN_ON(1) with an explicit -EINVAL return so the ioctl<br /> rejects the command before it reaches hardware.

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: 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 /> 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 /> inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush<br /> <br /> On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and<br /> flushes every fragment queue that is not yet complete using<br /> inet_frag_queue_flush(). That helper frees all the skbs queued on the<br /> fragment queue but does not set INET_FRAG_COMPLETE, and leaves<br /> q-&gt;fragments_tail and q-&gt;last_run_head pointing at the freed skbs.<br /> The queue itself stays in the rhashtable.<br /> <br /> fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups,<br /> but it cannot stop a fragment that already obtained the queue through<br /> inet_frag_find() earlier and stalled just before taking the queue lock.<br /> Once that fragment resumes after the flush and takes the queue lock,<br /> it passes the INET_FRAG_COMPLETE check and then dereferences the freed<br /> fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and -&gt;len of<br /> that pointer and, on the append path, writes -&gt;next_frag, causing a<br /> slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly<br /> share the same flush path and are affected as well.<br /> <br /> Reset rb_fragments, fragments_tail and last_run_head in<br /> inet_frag_queue_flush() so a flushed queue no longer points at the<br /> freed skbs. A fragment that resumes after the flush and takes the<br /> queue lock then finds an empty queue and starts a new run instead of<br /> dereferencing the freed fragments_tail. ip_frag_reinit() already<br /> performed this reset after its own flush, so drop the now duplicate<br /> code there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN<br /> <br /> In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done()<br /> computes the login request payload length as wc-&gt;byte_len minus<br /> ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int.<br /> A remote iSER initiator can post a login Send work request carrying<br /> fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows<br /> and login_req_len becomes negative.<br /> <br /> isert_rx_login_req() then reads that negative length back into a signed<br /> int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the<br /> min() is signed it keeps the negative value; the value is then passed as<br /> the memcpy() length and sign-extended to a multi-gigabyte size_t. The<br /> copy into the 8192-byte login-&gt;req_buf runs far out of bounds and<br /> faults, crashing the target node. The login phase precedes iSCSI<br /> authentication, so no credentials are required to reach this path.<br /> <br /> Reject any login PDU shorter than ISER_HEADERS_LEN before the<br /> subtraction, mirroring the existing early return on a failed work<br /> completion, so login_req_len can never go negative. The upper bound was<br /> already safe: a posted login buffer cannot deliver more than<br /> ISER_RX_PAYLOAD_SIZE, so the difference stays at or below<br /> MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing<br /> lower bound needs to be added.

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