Vulnerabilities

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.

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().

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

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.

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.

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.

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.

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.

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.

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.

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.

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.