Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix improper freeing of purex item<br /> <br /> In qla2xxx_process_purls_iocb(), an item is allocated via<br /> qla27xx_copy_multiple_pkt(), which internally calls<br /> qla24xx_alloc_purex_item().<br /> <br /> The qla24xx_alloc_purex_item() function may return a pre-allocated item<br /> from a per-adapter pool for small allocations, instead of dynamically<br /> allocating memory with kzalloc().<br /> <br /> An error handling path in qla2xxx_process_purls_iocb() incorrectly uses<br /> kfree() to release the item. If the item was from the pre-allocated<br /> pool, calling kfree() on it is a bug that can lead to memory corruption.<br /> <br /> Fix this by using the correct deallocation function,<br /> qla24xx_free_purex_item(), which properly handles both dynamically<br /> allocated and pre-allocated items.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix invalid prog-&gt;stats access when update_effective_progs fails<br /> <br /> Syzkaller triggers an invalid memory access issue following fault<br /> injection in update_effective_progs. The issue can be described as<br /> follows:<br /> <br /> __cgroup_bpf_detach<br /> update_effective_progs<br /> compute_effective_progs<br /> bpf_prog_array_alloc items[index] = &amp;dummy_bpf_prog.prog<br /> <br /> ---softirq start---<br /> __do_softirq<br /> ...<br /> __cgroup_bpf_run_filter_skb<br /> __bpf_prog_run_save_cb<br /> bpf_prog_run<br /> stats = this_cpu_ptr(prog-&gt;stats)<br /> /* invalid memory access */<br /> flags = u64_stats_update_begin_irqsave(&amp;stats-&gt;syncp)<br /> ---softirq end---<br /> <br /> static_branch_dec(&amp;cgroup_bpf_enabled_key[atype])<br /> <br /> The reason is that fault injection caused update_effective_progs to fail<br /> and then changed the original prog into dummy_bpf_prog.prog in<br /> purge_effective_progs. Then a softirq came, and accessing the members of<br /> dummy_bpf_prog.prog in the softirq triggers invalid mem access.<br /> <br /> To fix it, skip updating stats when stats is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv: Fix create memory region overlap check<br /> <br /> The current check is incorrect; it only checks if the beginning or end<br /> of a region is within an existing region. This doesn&amp;#39;t account for<br /> userspace specifying a region that begins before and ends after an<br /> existing region.<br /> <br /> Change the logic to a range intersection check against gfns and uaddrs<br /> for each region.<br /> <br /> Remove mshv_partition_region_by_uaddr() as it is no longer used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Free special fields when update [lru_,]percpu_hash maps<br /> <br /> As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing<br /> calls to &amp;#39;bpf_obj_free_fields()&amp;#39; in &amp;#39;pcpu_copy_value()&amp;#39; could cause the<br /> memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the<br /> map gets freed.<br /> <br /> Fix this by calling &amp;#39;bpf_obj_free_fields()&amp;#39; after<br /> &amp;#39;copy_map_value[,_long]()&amp;#39; in &amp;#39;pcpu_copy_value()&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Clear cmds after chip reset<br /> <br /> Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling<br /> and host reset handling") caused two problems:<br /> <br /> 1. Commands sent to FW, after chip reset got stuck and never freed as FW<br /> is not going to respond to them anymore.<br /> <br /> 2. BUG_ON(cmd-&gt;sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a<br /> ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands")<br /> attempted to fix this, but introduced another bug under different<br /> circumstances when two different CPUs were racing to call<br /> qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in<br /> dma_unmap_sg_attrs().<br /> <br /> So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and<br /> partially revert "scsi: qla2xxx: target: Fix offline port handling and<br /> host reset handling" at __qla2x00_abort_all_cmds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra210-quad: Fix timeout handling<br /> <br /> When the CPU that the QSPI interrupt handler runs on (typically CPU 0)<br /> is excessively busy, it can lead to rare cases of the IRQ thread not<br /> running before the transfer timeout is reached.<br /> <br /> While handling the timeouts, any pending transfers are cleaned up and<br /> the message that they correspond to is marked as failed, which leaves<br /> the curr_xfer field pointing at stale memory.<br /> <br /> To avoid this, clear curr_xfer to NULL upon timeout and check for this<br /> condition when the IRQ thread is finally run.<br /> <br /> While at it, also make sure to clear interrupts on failure so that new<br /> interrupts can be run.<br /> <br /> A better, more involved, fix would move the interrupt clearing into a<br /> hard IRQ handler. Ideally we would also want to signal that the IRQ<br /> thread no longer needs to be run after the timeout is hit to avoid the<br /> extra check for a valid transfer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix UAF on kernel BO VA nodes<br /> <br /> If the MMU is down, panthor_vm_unmap_range() might return an error.<br /> We expect the page table to be updated still, and if the MMU is blocked,<br /> the rest of the GPU should be blocked too, so no risk of accessing<br /> physical memory returned to the system (which the current code doesn&amp;#39;t<br /> cover for anyway).<br /> <br /> Proceed with the rest of the cleanup instead of bailing out and leaving<br /> the va_node inserted in the drm_mm, which leads to UAF when other<br /> adjacent nodes are removed from the drm_mm tree.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix UAF race between device unplug and FW event processing<br /> <br /> The function panthor_fw_unplug() will free the FW memory sections.<br /> The problem is that there could still be pending FW events which are yet<br /> not handled at this point. process_fw_events_work() can in this case try<br /> to access said freed memory.<br /> <br /> Simply call disable_work_sync() to both drain and prevent future<br /> invocation of process_fw_events_work().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix race condition when unbinding BOs<br /> <br /> Fix &amp;#39;Memory manager not clean during takedown&amp;#39; warning that occurs<br /> when ivpu_gem_bo_free() removes the BO from the BOs list before it<br /> gets unmapped. Then file_priv_unbind() triggers a warning in<br /> drm_mm_takedown() during context teardown.<br /> <br /> Protect the unmapping sequence with bo_list_lock to ensure the BO is<br /> always fully unmapped when removed from the list. This ensures the BO<br /> is either fully unmapped at context teardown time or present on the<br /> list and unmapped by file_priv_unbind().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Prevent potential UAF in group creation<br /> <br /> This commit prevents the possibility of a use after free issue in the<br /> GROUP_CREATE ioctl function, which arose as pointer to the group is<br /> accessed in that ioctl function after storing it in the Xarray.<br /> A malicious userspace can second guess the handle of a group and try<br /> to call GROUP_DESTROY ioctl from another thread around the same time<br /> as GROUP_CREATE ioctl.<br /> <br /> To prevent the use after free exploit, this commit uses a mark on an<br /> entry of group pool Xarray which is added just before returning from<br /> the GROUP_CREATE ioctl function. The mark is checked for all ioctls<br /> that specify the group handle and so userspace won&amp;#39;t be abe to delete<br /> a group that isn&amp;#39;t marked yet.<br /> <br /> v2: Add R-bs and fixes tags

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix handling of disconnected directories<br /> <br /> Disconnected files or directories can appear when they are visible and<br /> opened from a bind mount, but have been renamed or moved from the source<br /> of the bind mount in a way that makes them inaccessible from the mount<br /> point (i.e. out of scope).<br /> <br /> Previously, access rights tied to files or directories opened through a<br /> disconnected directory were collected by walking the related hierarchy<br /> down to the root of the filesystem, without taking into account the<br /> mount point because it couldn&amp;#39;t be found. This could lead to<br /> inconsistent access results, potential access right widening, and<br /> hard-to-debug renames, especially since such paths cannot be printed.<br /> <br /> For a sandboxed task to create a disconnected directory, it needs to<br /> have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to<br /> the underlying source of the bind mount, and read access to the related<br /> mount point. Because a sandboxed task cannot acquire more access<br /> rights than those defined by its Landlock domain, this could lead to<br /> inconsistent access rights due to missing permissions that should be<br /> inherited from the mount point hierarchy, while inheriting permissions<br /> from the filesystem hierarchy hidden by this mount point instead.<br /> <br /> Landlock now handles files and directories opened from disconnected<br /> directories by taking into account the filesystem hierarchy when the<br /> mount point is not found in the hierarchy walk, and also always taking<br /> into account the mount point from which these disconnected directories<br /> were opened. This ensures that a rename is not allowed if it would<br /> widen access rights [1].<br /> <br /> The rationale is that, even if disconnected hierarchies might not be<br /> visible or accessible to a sandboxed task, relying on the collected<br /> access rights from them improves the guarantee that access rights will<br /> not be widened during a rename because of the access right comparison<br /> between the source and the destination (see LANDLOCK_ACCESS_FS_REFER).<br /> It may look like this would grant more access on disconnected files and<br /> directories, but the security policies are always enforced for all the<br /> evaluated hierarchies. This new behavior should be less surprising to<br /> users and safer from an access control perspective.<br /> <br /> Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and<br /> fix the related comment.<br /> <br /> Because opened files have their access rights stored in the related file<br /> security properties, there is no impact for disconnected or unlinked<br /> files.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/pageattr: Propagate return value from __change_memory_common<br /> <br /> The rodata=on security measure requires that any code path which does<br /> vmalloc -&gt; set_memory_ro/set_memory_rox must protect the linear map alias<br /> too. Therefore, if such a call fails, we must abort set_memory_* and caller<br /> must take appropriate action; currently we are suppressing the error, and<br /> there is a real chance of such an error arising post commit a166563e7ec3<br /> ("arm64: mm: support large block mapping when rodata=full"). Therefore,<br /> propagate any error to the caller.