Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate()<br /> <br /> The command stream parsing loop increments the index variable a second<br /> time when a 64-bit command word is encountered (bit 14 set), but does<br /> not re-check the loop bound before writing the second word:<br /> <br /> for (i = 0; i

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: fix IFM region index out-of-bounds in command stream parser<br /> <br /> NPU_SET_IFM_REGION extracts the region index with param &amp; 0x7f, giving<br /> a maximum value of 127. However region_size[] and output_region[] in<br /> struct ethosu_validated_cmdstream_info are both sized to<br /> NPU_BASEP_REGION_MAX (8), giving valid indices [0..7].<br /> <br /> Every other region assignment in the same switch uses param &amp; 0x7:<br /> NPU_SET_OFM_REGION: st.ofm.region = param &amp; 0x7;<br /> NPU_SET_IFM2_REGION: st.ifm2.region = param &amp; 0x7;<br /> NPU_SET_WEIGHT_REGION: st.weight[0].region = param &amp; 0x7;<br /> NPU_SET_SCALE_REGION: st.scale[0].region = param &amp; 0x7;<br /> <br /> The 0x7f mask on IFM is inconsistent and appears to be a typo.<br /> <br /> feat_matrix_length() and calc_sizes() use the region index directly<br /> as an array subscript into the kzalloc&amp;#39;d info struct:<br /> info-&gt;region_size[fm-&gt;region] = max(...);<br /> <br /> A userspace caller supplying NPU_SET_IFM_REGION with param &gt; 7 causes<br /> a write up to 127*8 = 1016 bytes past the start of region_size[],<br /> corrupting adjacent kernel heap data.<br /> <br /> Fix by applying the same &amp; 0x7 mask used by all other region<br /> assignments.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: fix arithmetic issues in dma_length()<br /> <br /> dma_length() derives DMA region usage from command stream values and<br /> updates region_size[]:<br /> <br /> len = ((len + stride[0]) * size0 + stride[1]) * size1<br /> region_size[region] = max(..., len + dma-&gt;offset)<br /> <br /> Several arithmetic issues can corrupt the derived region size:<br /> <br /> - signed stride values may underflow when added to len<br /> - intermediate multiplications may overflow<br /> - len + dma-&gt;offset may overflow during region_size updates<br /> - dma_length() error returns were not validated by the caller<br /> <br /> region_size[] is later used by ethosu_job.c to validate command stream<br /> accesses against GEM buffer sizes. Arithmetic wraparound can therefore<br /> under-report region usage and bypass the bounds validation.<br /> <br /> Fix by validating signed additions, using overflow helpers for<br /> multiplications and offset updates, and propagating dma_length()<br /> failures to the caller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: reject DMA commands with uninitialized length<br /> <br /> cmd_state_init() initializes the command state with memset(0xff),<br /> leaving dma-&gt;len at U64_MAX to signal missing setup. The only setter<br /> is NPU_SET_DMA0_LEN; if userspace omits this command and issues<br /> NPU_OP_DMA_START, dma-&gt;len remains U64_MAX.<br /> <br /> In dma_length(), a positive stride added to U64_MAX wraps to a small<br /> value. With size0 == 1, check_mul_overflow() does not trigger and<br /> dma_length() returns 0 instead of U64_MAX. The caller&amp;#39;s U64_MAX check<br /> then passes, region_size[] stays 0, and the bounds check in<br /> ethosu_job.c is bypassed, allowing hardware to execute DMA with stale<br /> physical addresses.<br /> <br /> Fix by checking for U64_MAX at the start of dma_length() before any<br /> arithmetic, consistent with the sentinel value used throughout the<br /> driver to detect uninitialized fields.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.