Vulnerabilidades

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.32.5, Budibase's Builder Command Palette renders entity names (tables, views, queries, automations) using Svelte's {@html} directive without any sanitization. An authenticated user with Builder access can create a table, automation, view, or query whose name contains an HTML payload (e.g. ). When any Builder-role user in the same workspace opens the Command Palette (Ctrl+K), the payload executes in their browser, stealing their session cookie and enabling full account takeover. This issue has been patched in version 3.32.5.

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.33.4, an unauthenticated attacker can achieve Remote Code Execution (RCE) on the Budibase server by triggering an automation that contains a Bash step via the public webhook endpoint. No authentication is required to trigger the exploit. The process executes as root inside the container. This issue has been patched in version 3.33.4.

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.33.4, the plugin file upload endpoint (POST /api/plugin/upload) passes the user-supplied filename directly to createTempFolder() without sanitizing path traversal sequences. An attacker with Global Builder privileges can craft a multipart upload with a filename containing ../ to delete arbitrary directories via rmSync and write arbitrary files via tarball extraction to any filesystem path the Node.js process can access. This issue has been patched in version 3.33.4.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: bpf: prevent buffer overflow in hid_hw_request<br /> <br /> right now the returned value is considered to be always valid. However,<br /> when playing with HID-BPF, the return value can be arbitrary big,<br /> because it&amp;#39;s the return value of dispatch_hid_bpf_raw_requests(), which<br /> calls the struct_ops and we have no guarantees that the value makes<br /> sense.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix heap overflow in NFSv4.0 LOCK replay cache<br /> <br /> The NFSv4.0 replay cache uses a fixed 112-byte inline buffer<br /> (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.<br /> This size was calculated based on OPEN responses and does not account<br /> for LOCK denied responses, which include the conflicting lock owner as<br /> a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).<br /> <br /> When a LOCK operation is denied due to a conflict with an existing lock<br /> that has a large owner, nfsd4_encode_operation() copies the full encoded<br /> response into the undersized replay buffer via read_bytes_from_xdr_buf()<br /> with no bounds check. This results in a slab-out-of-bounds write of up<br /> to 944 bytes past the end of the buffer, corrupting adjacent heap memory.<br /> <br /> This can be triggered remotely by an unauthenticated attacker with two<br /> cooperating NFSv4.0 clients: one sets a lock with a large owner string,<br /> then the other requests a conflicting lock to provoke the denial.<br /> <br /> We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full<br /> opaque, but that would increase the size of every stateowner, when most<br /> lockowners are not that large.<br /> <br /> Instead, fix this by checking the encoded response length against<br /> NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the<br /> response is too large, set rp_buflen to 0 to skip caching the replay<br /> payload. The status is still cached, and the client already received the<br /> correct response on the original request.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd<br /> <br /> The /proc/fs/nfs/exports proc entry is created at module init<br /> and persists for the module&amp;#39;s lifetime. exports_proc_open()<br /> captures the caller&amp;#39;s current network namespace and stores<br /> its svc_export_cache in seq-&gt;private, but takes no reference<br /> on the namespace. If the namespace is subsequently torn down<br /> (e.g. container destruction after the opener does setns() to a<br /> different namespace), nfsd_net_exit() calls nfsd_export_shutdown()<br /> which frees the cache. Subsequent reads on the still-open fd<br /> dereference the freed cache_detail, walking a freed hash table.<br /> <br /> Hold a reference on the struct net for the lifetime of the open<br /> file descriptor. This prevents nfsd_net_exit() from running --<br /> and thus prevents nfsd_export_shutdown() from freeing the cache<br /> -- while any exports fd is open. cache_detail already stores<br /> its net pointer (cd-&gt;net, set by cache_create_net()), so<br /> exports_release() can retrieve it without additional per-file<br /> storage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Defer sub-object cleanup in export put callbacks<br /> <br /> svc_export_put() calls path_put() and auth_domain_put() immediately<br /> when the last reference drops, before the RCU grace period. RCU<br /> readers in e_show() and c_show() access both ex_path (via<br /> seq_path/d_path) and ex_client-&gt;name (via seq_escape) without<br /> holding a reference. If cache_clean removes the entry and drops the<br /> last reference concurrently, the sub-objects are freed while still<br /> in use, producing a NULL pointer dereference in d_path.<br /> <br /> Commit 2530766492ec ("nfsd: fix UAF when access ex_uuid or<br /> ex_stats") moved kfree of ex_uuid and ex_stats into the<br /> call_rcu callback, but left path_put() and auth_domain_put() running<br /> before the grace period because both may sleep and call_rcu<br /> callbacks execute in softirq context.<br /> <br /> Replace call_rcu/kfree_rcu with queue_rcu_work(), which defers the<br /> callback until after the RCU grace period and executes it in process<br /> context where sleeping is permitted. This allows path_put() and<br /> auth_domain_put() to be moved into the deferred callback alongside<br /> the other resource releases. Apply the same fix to expkey_put(),<br /> which has the identical pattern with ek_path and ek_client.<br /> <br /> A dedicated workqueue scopes the shutdown drain to only NFSD<br /> export release work items; flushing the shared<br /> system_unbound_wq would stall on unrelated work from other<br /> subsystems. nfsd_export_shutdown() uses rcu_barrier() followed<br /> by flush_workqueue() to ensure all deferred release callbacks<br /> complete before the export caches are destroyed.<br /> <br /> Reviwed-by: Jeff Layton

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.33.4, a server-side request forgery (SSRF) vulnerability exists in Budibase&amp;#39;s REST datasource connector. The platform&amp;#39;s SSRF protection mechanism (IP blacklist) is rendered completely ineffective because the BLACKLIST_IPS environment variable is not set by default in any of the official deployment configurations. When this variable is empty, the blacklist function unconditionally returns false, allowing all requests through without restriction. This issue has been patched in version 3.33.4.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd()<br /> <br /> move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge<br /> zero pages. For the huge zero page path, src_folio is explicitly set to<br /> NULL, and is used as a sentinel to skip folio operations like lock and<br /> rmap.<br /> <br /> In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL,<br /> pgprot) passes NULL through folio_pfn() and page_to_pfn(). With<br /> SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD<br /> pointing to non-existent physical memory. On other memory models it is a<br /> NULL dereference.<br /> <br /> Use page_folio(src_page) to obtain the valid huge zero folio from the<br /> page, which was obtained from pmd_page() and remains valid throughout.<br /> <br /> After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge<br /> zero folio special"), moved huge zero PMDs must remain special so<br /> vm_normal_page_pmd() continues to treat them as special mappings.<br /> <br /> move_pages_huge_pmd() currently reconstructs the destination PMD in the<br /> huge zero page branch, which drops PMD state such as pmd_special() on<br /> architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result,<br /> vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page<br /> and corrupt its refcount.<br /> <br /> Instead of reconstructing the PMD from the folio, derive the destination<br /> entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD<br /> metadata the same way move_huge_pmd() does for moved entries by marking it<br /> soft-dirty and clearing uffd-wp.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/rmap: fix incorrect pte restoration for lazyfree folios<br /> <br /> We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the<br /> batch has a mix of writable and non-writable bits, we may end up setting<br /> the entire batch writable. Fix this by respecting writable bit during<br /> batching.<br /> <br /> Although on a successful unmap of a lazyfree folio, the soft-dirty bit is<br /> lost, preserve it on pte restoration by respecting the bit during<br /> batching, to make the fix consistent w.r.t both writable bit and<br /> soft-dirty bit.<br /> <br /> I was able to write the below reproducer and crash the kernel. <br /> Explanation of reproducer (set 64K mTHP to always):<br /> <br /> Fault in a 64K large folio. Split the VMA at mid-point with<br /> MADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes<br /> and 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that<br /> folio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do<br /> MADV_FREE on the range to mark the folio as lazyfree. Write to the memory<br /> to dirty the pte, eventually rmap will dirty the folio. Then trigger<br /> reclaim, we will hit the pte restoration path, and the kernel will crash<br /> with the trace given below.<br /> <br /> The BUG happens at:<br /> <br /> BUG_ON(atomic_inc_return(&amp;ptc-&gt;anon_map_count) &gt; 1 &amp;&amp; rw);<br /> <br /> The code path is asking for anonymous page to be mapped writable into the<br /> pagetable. The BUG_ON() firing implies that such a writable page has been<br /> mapped into the pagetables of more than one process, which breaks<br /> anonymous memory/CoW semantics.<br /> <br /> [ 21.134473] kernel BUG at mm/page_table_check.c:118!<br /> [ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 21.135917] Modules linked in:<br /> [ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT<br /> [ 21.136858] Hardware name: linux,dummy-virt (DT)<br /> [ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 21.137308] pc : page_table_check_set+0x28c/0x2a8<br /> [ 21.137607] lr : page_table_check_set+0x134/0x2a8<br /> [ 21.137885] sp : ffff80008a3b3340<br /> [ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000<br /> [ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001<br /> [ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30<br /> [ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000<br /> [ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff<br /> [ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020<br /> [ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0<br /> [ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff<br /> [ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002<br /> [ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0<br /> [ 21.141991] Call trace:<br /> [ 21.142093] page_table_check_set+0x28c/0x2a8 (P)<br /> [ 21.142265] __page_table_check_ptes_set+0x144/0x1e8<br /> [ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8<br /> [ 21.142766] contpte_set_ptes+0xe8/0x140<br /> [ 21.142907] try_to_unmap_one+0x10c4/0x10d0<br /> [ 21.143177] rmap_walk_anon+0x100/0x250<br /> [ 21.143315] try_to_unmap+0xa0/0xc8<br /> [ 21.143441] shrink_folio_list+0x59c/0x18a8<br /> [ 21.143759] shrink_lruvec+0x664/0xbf0<br /> [ 21.144043] shrink_node+0x218/0x878<br /> [ 21.144285] __node_reclaim.constprop.0+0x98/0x338<br /> [ 21.144763] user_proactive_reclaim+0x2a4/0x340<br /> [ 21.145056] reclaim_store+0x3c/0x60<br /> [ 21.145216] dev_attr_store+0x20/0x40<br /> [ 21.145585] sysfs_kf_write+0x84/0xa8<br /> [ 21.145835] kernfs_fop_write_iter+0x130/0x1c8<br /> [ 21.145994] vfs_write+0x2b8/0x368<br /> [ 21.146119] ksys_write+0x70/0x110<br /> [ 21.146240] __arm64_sys_write+0x24/0x38<br /> [ 21.146380] invoke_syscall+0x50/0x120<br /> [ 21.146513] el0_svc_common.constprop.0+0x48/0xf8<br /> [ 21.146679] do_el0_svc+0x28/0x40<br /> [ 21.146798] el0_svc+0x34/0x110<br /> [ 21.146926] el0t<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvdimm/bus: Fix potential use after free in asynchronous initialization<br /> <br /> Dingisoul with KASAN reports a use after free if device_add() fails in<br /> nd_async_device_register().<br /> <br /> Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while<br /> scheduling async init") correctly added a reference on the parent device<br /> to be held until asynchronous initialization was complete. However, if<br /> device_add() results in an allocation failure the ref count of the<br /> device drops to 0 prior to the parent pointer being accessed. Thus<br /> resulting in use after free.<br /> <br /> The bug bot AI correctly identified the fix. Save a reference to the<br /> parent pointer to be used to drop the parent reference regardless of the<br /> outcome of device_add().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix cache_request leak in cache_release<br /> <br /> When a reader&amp;#39;s file descriptor is closed while in the middle of reading<br /> a cache_request (rp-&gt;offset != 0), cache_release() decrements the<br /> request&amp;#39;s readers count but never checks whether it should free the<br /> request.<br /> <br /> In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the<br /> cache_request is removed from the queue and freed along with its buffer<br /> and cache_head reference. cache_release() lacks this cleanup.<br /> <br /> The only other path that frees requests with readers == 0 is<br /> cache_dequeue(), but it runs only when CACHE_PENDING transitions from<br /> set to clear. If that transition already happened while readers was<br /> still non-zero, cache_dequeue() will have skipped the request, and no<br /> subsequent call will clean it up.<br /> <br /> Add the same cleanup logic from cache_read() to cache_release(): after<br /> decrementing readers, check if it reached 0 with CACHE_PENDING clear,<br /> and if so, dequeue and free the cache_request.