Vulnerabilidades

*** Pendiente de traducción *** Meshtastic is an open source mesh networking solution. Prior to version 2.7.21.1370b23, the Meshtastic GitHub repository's main_matrix.yml workflow is triggered by pull_request_target and multiple jobs check out the attacker's fork code and execute it with access to repository secrets and elevated GITHUB_TOKEN permissions. No approval gate exists. Pull requests from external users with author_association: "NONE" triggered the CI workflow automatically. The workflow directly executes attacker-controlled files from the fork checkout. This issue could have resulted in supply chain compromise, self-hosted runner compromise, and/or repository takeover for the repo. This issue is separate from GHSA-6mwm-v2vv-pp96, which addressed a command injection via github.head_ref in the setup job of the same workflow. That fix correctly moved to environment variables. However, the more critical fork checkout vulnerability across the check, build, and build-debian-src jobs was not addressed. Version 2.7.21.1370b23 contains a patch for thie issue.

*** Pendiente de traducción *** CI4MS is a CodeIgniter 4-based content management system skeleton. Prior to version 0.31.9.0, the custom `html_purify` validation rule used to sanitize blog post bodies relies on by-reference mutation (`?string &$str`), but CodeIgniter 4's validator passes a local copy of the value, so the sanitized text is silently discarded. The Blog controller writes `$lanData['content']` directly into `blog_langs.content`, and the public template echoes it without escaping — yielding stored XSS executable in any visitor's browser, including the superadmin when previewing or editing posts. Version 0.31.9.0 patches the issue.

*** Pendiente de traducción *** A vulnerability in keras-team/keras version 3.15.0 allows unsafe deserialization of attacker-controlled PyTorch pickle data through the public `keras.layers.TorchModuleWrapper.from_config` method. This method invokes `torch.load(..., weights_only=False)` without requiring an explicit unsafe opt-in, such as a `safe_mode=False` parameter. When called outside a `SafeModeScope(True)` context, the absence of an ambient safe mode state permits unsafe deserialization by default. This issue can lead to arbitrary code execution if untrusted Keras layer configurations are processed using this method. The vulnerability arises because the method does not enforce safe deserialization practices unless explicitly guarded by Keras safe mode.

*** 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.