Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Check for NULL FF-A ID table while driver registration<br /> <br /> The bus match callback assumes that every FF-A driver provides an<br /> id_table and dereferences it unconditionally. Enforce that contract at<br /> registration time so a buggy client driver cannot crash the bus during<br /> match.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kho: skip KHO for crash kernel<br /> <br /> kho_fill_kimage() unconditionally populates the kimage with KHO<br /> metadata for every kexec image type. When the image is a crash kernel,<br /> this can be problematic as the crash kernel can run in a small reserved<br /> region and the KHO scratch areas can sit outside it.<br /> The crash kernel then faults during kho_memory_init() when it<br /> tries phys_to_virt() on the KHO FDT address:<br /> <br /> Unable to handle kernel paging request at virtual address xxxxxxxx<br /> ...<br /> fdt_offset_ptr+...<br /> fdt_check_node_offset_+...<br /> fdt_first_property_offset+...<br /> fdt_get_property_namelen_+...<br /> fdt_getprop+...<br /> kho_memory_init+...<br /> mm_core_init+...<br /> start_kernel+...<br /> <br /> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH<br /> images, but kho_fill_kimage() was missing the same guard. As<br /> kho_fill_kimage() is the single point that populates image-&gt;kho.fdt<br /> and image-&gt;kho.scratch, fixing it here is sufficient for both arm64<br /> and x86 as the FDT and boot_params path are bailing out when these<br /> fields are unset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sprd: fix error pointer deref after DMA setup failure<br /> <br /> The driver falls back to PIO mode if DMA setup fails during probe.<br /> <br /> Make sure to check the dma.enabled flag before trying to release the DMA<br /> channels also on late probe errors to avoid dereferencing an error<br /> pointer (or attempting to release a channel a second time).<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap<br /> <br /> Sashiko pointed out that the driver could drop PAGE_SIZE from the<br /> pgsize_bitmap. That is technically allowed but nothing does it, and<br /> such an iommu_domain would not be used with the DMA API today.<br /> <br /> Still, it is against the design and it is trivial to fix up. Lift<br /> the PT_WARN_ON to the if branch and just skip the fast path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Handle unmap error when iommu_debug is enabled<br /> <br /> Sashiko noticed a latent bug where the map error flow called iommu_unmap()<br /> which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however<br /> since this is an error path the map flow never actually established the<br /> original iommu_debug_map() it will malfunction.<br /> <br /> Lift the unmap error handling into iommu_map_nosync() and reorder it so<br /> the trace_map()/iommu_debug_map() records the partial mapping and then<br /> immediately unmaps it. This avoid creating the unbalanced tracking and<br /> provides saner tracing instead of a unmap unmatched to any map.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN<br /> <br /> Commit "iommu: return full error code from iommu_map_sg[_atomic]()"<br /> changed iommu_map_sgtable() to return an ssize_t and negative values<br /> in error cases, rather than a size_t and a zero.<br /> <br /> Store the return value in the appropriate type and in case of error,<br /> return it rather than WARNing.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/719685/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: Fix a reference leak in a6xx_gpu_init()<br /> <br /> In a6xx_gpu_init(), node is obtained via of_parse_phandle().<br /> While there was a manual of_node_put() at the end of the<br /> common path, several early error returns would bypass this call,<br /> resulting in a reference leak.<br /> Fix this by using the __free(device_node) cleanup handler to<br /> release the reference when the variable goes out of scope.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/700661/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix error path leaks in some WMI WOW calls<br /> <br /> Fix two instances where we used to directly return the result of<br /> ath11k_wmi_cmd_send(...). Because we did not check the return value, we<br /> also did not free the skb in the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs, afs: Fix write skipping in dir/link writepages<br /> <br /> Fix netfs_write_single() and afs_single_writepages() to better handle a<br /> write that would be skipped due to lock contention and WB_SYNC_NONE by<br /> returning 1 from netfs_write_single() if it skipped and making<br /> afs_single_writepages() skip also. If a skip occurs, the inode must be<br /> re-marked as the VFS may have cleared the mark.<br /> <br /> This is really only theoretical for directories in netfs_write_single() as<br /> the only path to that is through afs_single_writepages() that takes the<br /> -&gt;validate_lock around it, thereby serialising it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix partial invalidation of streaming-write folio<br /> <br /> In netfs_invalidate_folio(), if the region of a partial invalidation<br /> overlaps the front (but not all) of a dirty write cached in a streaming<br /> write page (dirty, but not uptodate, with the dirty region tracked by a<br /> netfs_folio struct), the function modifies the dirty region - but<br /> incorrectly as it moves the region forward by setting the start to the<br /> start, not the end, of the invalidation region.<br /> <br /> Fix this by setting finfo-&gt;dirty_offset to the end of the invalidation<br /> region (iend).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix write streaming disablement if fd open O_RDWR<br /> <br /> In netfs_perform_write(), "write streaming" (the caching of dirty data in<br /> dirty but !uptodate folios) is performed to avoid the need to read data<br /> that is just going to get immediately overwritten. However, this is/will<br /> be disabled in three circumstances: if the fd is open O_RDWR, if fscache is<br /> in use (as we need to round out the blocks for DIO) or if content<br /> encryption is enabled (again for rounding out purposes).<br /> <br /> The idea behind disabling it if the fd is open O_RDWR is that we&amp;#39;d need to<br /> flush the write-streaming page before we could read the data, particularly<br /> through mmap. But netfs now fills in the gaps if -&gt;read_folio() is called<br /> on the page, so that is unnecessary. Further, this doesn&amp;#39;t actually work<br /> if a separate fd is open for reading.<br /> <br /> Fix this by removing the check for O_RDWR, thereby allowing streaming<br /> writes even when we might read.<br /> <br /> This caused a number of problems with the generic/522 xfstest, but those<br /> are now fixed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix zeropoint update where i_size &gt; remote_i_size<br /> <br /> Fix the update of the zero point[*] by netfs_release_folio() when there is<br /> uncommitted data in the pagecache beyond the folio being released but the<br /> on-server EOF is in this folio (ie. i_size &gt; remote_i_size). The update<br /> needs to limit zero_point to remote_i_size, not i_size as i_size is a local<br /> phenomenon reflecting updates made locally to the pagecache, not stuff<br /> written to the server. remote_i_size tracks the server&amp;#39;s i_size.<br /> <br /> [*] The zero point is the file position from which we can assume that the<br /> server will just return zeros, so we can avoid generating reads.<br /> <br /> Note that netfs_invalidate_folio() probably doesn&amp;#39;t need fixing as<br /> zero_point should be updated by setattr after truncation or fallocate.<br /> <br /> Found with:<br /> <br /> fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \<br /> /xfstest.test/junk --replay-ops=junk.fsxops<br /> <br /> using the following as junk.fsxops:<br /> <br /> truncate 0x0 0x1bbae 0x82864<br /> write 0x3ef2e 0xf9c8 0x1bbae<br /> write 0x67e05 0xcb5a 0x4e8f6<br /> mapread 0x57781 0x85b6 0x7495f<br /> copy_range 0x5d3d 0x10329 0x54fac 0x7495f<br /> write 0x64710 0x1c2b 0x7495f<br /> mapread 0x64000 0x1000 0x7495f<br /> <br /> on cifs with the default cache option.<br /> <br /> It shows read-gaps on folio 0x64 failing with a short read (ie. it hits<br /> EOF) if the FMODE_READ check is commented out in netfs_perform_write():<br /> <br /> if (//(file-&gt;f_mode &amp; FMODE_READ) ||<br /> netfs_is_cache_enabled(ctx)) {<br /> <br /> and no fscache. This was initially found with the generic/522 xfstest.