Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs<br /> <br /> In iommu_mmio_write() and iommu_capability_write(), the variables<br /> dbg_mmio_offset and dbg_cap_offset are declared as int. However, they<br /> are populated using kstrtou32_from_user(). If a user provides a<br /> sufficiently large value, it can become a negative integer.<br /> <br /> Prior to this patch, the AMD IOMMU debugfs implementation was already<br /> protected by different mechanisms.<br /> <br /> 1. #define OFS_IN_SZ 8 ensures the user string OFS_IN_SZ)<br /> return -EINVAL;<br /> <br /> 2. Implicit type promotion in iommu_mmio_write(), dbg_mmio_offset is int<br /> and iommu-&gt;mmio_phys_end is u64<br /> <br /> if (dbg_mmio_offset &gt; iommu-&gt;mmio_phys_end - sizeof(u64))<br /> return -EINVAL;<br /> <br /> 3. The show handlers would currently catch the negative number and<br /> refuse to perform the read.<br /> <br /> Replace kstrtou32_from_user() with kstrtos32_from_user() to parse the<br /> input, and check for negative values to explicitly prevent out-of-bounds<br /> memory accesses directly in iommu_mmio_write() and<br /> iommu_capability_write().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bnep: Fix UAF read of dev-&gt;name<br /> <br /> bnep_add_connection() needs to keep holding the bnep_session_sem while<br /> reading dev-&gt;name (just like bnep_get_connlist() does); otherwise the<br /> bnep_session() thread can concurrently free the net_device, which can for<br /> example be triggered by a concurrent bnep_del_connection().<br /> <br /> (This UAF is fairly uninteresting from a security perspective;<br /> calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN)<br /> check. It also requires completely tearing down a netdev during a fairly<br /> tight race window.)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: fix potential memory leaks in ipc_imem_init()<br /> <br /> The memory allocated in ipc_protocol_init() is not freed on the error<br /> paths that follow in ipc_imem_init(). Fix that by calling the<br /> corresponding release function ipc_protocol_deinit() in the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory_hotplug: fix memory block reference leak on remove<br /> <br /> Patch series "mm: Fix memory block leaks and locking", v2.<br /> <br /> This series fixes two memory block device reference leaks and one locking<br /> issue around the per-memory_block hwpoison counter.<br /> <br /> <br /> This patch (of 2):<br /> <br /> remove_memory_blocks_and_altmaps() looks up each memory block with<br /> find_memory_block(), which acquires a reference to the memory block<br /> device.<br /> <br /> That reference is never dropped on this path, resulting in a leaked device<br /> reference when removing memory blocks and their altmaps. Drop the<br /> reference after retrieving mem-&gt;altmap and clearing mem-&gt;altmap, before<br /> removing the memory block device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()<br /> <br /> On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a<br /> "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the<br /> VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by<br /> "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when<br /> reclaim gets to call shrink_huge_zero_folio_scan().<br /> <br /> It&amp;#39;s as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and<br /> indeed, whereas pte_special() and pte_mkspecial() are subject to a<br /> dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial()<br /> are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on<br /> any 32-bit architecture.<br /> <br /> While the problem was exposed through commit d80a9cb1a64a<br /> ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), it was an<br /> oversight in commit af38538801c6 ("mm/memory: factor out common code from<br /> vm_normal_page_*()") and would result in other problems:<br /> * huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and<br /> numamaps as file-backed THP<br /> * folio_walk_start() returning the folio even without FW_ZEROPAGE set.<br /> Callers seem to tolerate that, though.<br /> <br /> ... and triggering the VM_WARN_ON_ONE(), although never reported so far.<br /> <br /> To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider<br /> whether pmd_special/pud_special is actually implemented.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/base/memory: fix memory block reference leak in poison accounting<br /> <br /> memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block<br /> via find_memory_block_by_id(), which acquires a reference to the memory<br /> block device.<br /> <br /> Both helpers use the returned memory block without dropping that<br /> reference, leaking the device reference on each successful lookup. Drop<br /> the reference after updating nr_hwpoison.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: Allocate runtime workqueue before ACPI init<br /> <br /> Since commit<br /> <br /> 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")<br /> <br /> ACPI PRM calls are delegated to a workqueue which runs in a kernel<br /> thread, making it easier to detect and mitigate faulting memory accesses<br /> performed by the firmware.<br /> <br /> Rafael reports that such PRM accesses may occur before efisubsys_init()<br /> executes, which is where the workqueue is allocated, leading to NULL<br /> pointer dereferences. Since acpi_init() [which triggers the early PRM<br /> accesses] executes as a subsys_initcall() as well, and has its own<br /> dependencies that may be sensitive to initcall ordering, deferring<br /> acpi_init() is not an option.<br /> <br /> So instead, split off the workqueue allocation into its own postcore<br /> initcall, as this is the only missing piece to allow EFI runtime calls<br /> to be made. This ensures that EFI runtime call (including PRM calls) are<br /> accessible to all code running at subsys_initcall() level.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break()<br /> <br /> damon_sysfs_memcg_path_to_id() breaks mem_cgroup_iter() loop without<br /> calling mem_cgroup_iter_break(). This leaks the cgroup reference. Fix<br /> the issue by calling mem_cgroup_iter_break() before the break.<br /> <br /> The issue was discovered [1] by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysfs: don&amp;#39;t remove existing directory on update failure<br /> <br /> When sysfs_update_group() is called for a named group and create_files()<br /> fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on<br /> the group directory. In the update path, kn was obtained via<br /> kernfs_find_and_get() and refers to a directory that already existed<br /> before this call. Removing it silently destroys a sysfs group that the<br /> caller did not create.<br /> <br /> Only remove the directory if we created it ourselves. On update failure<br /> the directory remains as it is left empty by remove_files() inside<br /> create_files(), but can be repopulated by a retry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix driver-set TX rates on old devices<br /> <br /> On old devices such as 7265D, rates are still encoded in version 1<br /> format, which doesn&amp;#39;t use the CCK/OFDM rate index (0-3/0-7) but<br /> rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.)<br /> <br /> While introducing v3 rates, I changed the driver from internally<br /> handling v1 rates and converting to v2, to internally handling v3<br /> and converting to v1 or v2 according to the firmware. I accordingly<br /> changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer<br /> have different values for different APIs. This was correct.<br /> <br /> However, I later reverted this part of the change, because it was<br /> reported that I had broken beacon rates, causing a FW assert/crash.<br /> This caused TX_CMD rates to be set incorrectly, potentially causing<br /> a warning when reported back from the device as having been used.<br /> <br /> Fix this (hopefully correctly now) by handling beacon rates in the<br /> TX_CMD that&amp;#39;s embedded in the beacon template command separately.<br /> Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate<br /> index, not PLCP value, fixing the real TX_CMD.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: ep93xx: 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 the clear the DMA channel pointers on setup failure to<br /> avoid dereferencing an error pointer on later probe errors or driver<br /> unbind.<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 /> spi: qup: 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 the clear the DMA channel pointers on setup failure to<br /> avoid dereferencing an error pointer (or attempting to release a channel<br /> a second time) on later probe errors or driver unbind.<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.