Vulnerabilities

Budibase is an open-source low-code platform. Prior to version 3.33.4, a server-side request forgery (SSRF) vulnerability exists in Budibase's REST datasource connector. The platform'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.

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.

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

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-sha204a - Fix OOM -&gt;tfm_count leak<br /> <br /> If memory allocation fails, decrement -&gt;tfm_count to avoid blocking<br /> future reads.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix krb5 mount with username option<br /> <br /> Customer reported that some of their krb5 mounts were failing against<br /> a single server as the client was trying to mount the shares with<br /> wrong credentials. It turned out the client was reusing SMB session<br /> from first mount to try mounting the other shares, even though a<br /> different username= option had been specified to the other mounts.<br /> <br /> By using username mount option along with sec=krb5 to search for<br /> principals from keytab is supported by cifs.upcall(8) since<br /> cifs-utils-4.8. So fix this by matching username mount option in<br /> match_session() even with Kerberos.<br /> <br /> For example, the second mount below should fail with -ENOKEY as there<br /> is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab). The client<br /> ends up reusing SMB session from first mount to perform the second<br /> one, which is wrong.<br /> <br /> ```<br /> $ ktutil<br /> ktutil: add_entry -password -p testuser -k 1 -e aes256-cts<br /> Password for testuser@ZELDA.TEST:<br /> ktutil: write_kt /etc/krb5.keytab<br /> ktutil: quit<br /> $ klist -ke<br /> Keytab name: FILE:/etc/krb5.keytab<br /> KVNO Principal<br /> ---- ----------------------------------------------------------------<br /> 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)<br /> $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser<br /> $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar<br /> $ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;<br /> testuser<br /> testuser<br /> ```

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access<br /> <br /> l2cap_information_rsp() checks that cmd_len covers the fixed<br /> l2cap_info_rsp header (type + result, 4 bytes) but then reads<br /> rsp-&gt;data without verifying that the payload is present:<br /> <br /> - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-&gt;data), which reads<br /> 4 bytes past the header (needs cmd_len &gt;= 8).<br /> <br /> - L2CAP_IT_FIXED_CHAN reads rsp-&gt;data[0], 1 byte past the header<br /> (needs cmd_len &gt;= 5).<br /> <br /> A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an<br /> out-of-bounds read of adjacent skb data.<br /> <br /> Guard each data access with the required payload length check. If the<br /> payload is too short, skip the read and let the state machine complete<br /> with safe defaults (feat_mask and remote_fixed_chan remain zero from<br /> kzalloc), so the info timer cleanup and l2cap_conn_start() still run<br /> and the connection is not stalled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations<br /> <br /> ieee80211_chan_bw_change() iterates all stations and accesses<br /> link-&gt;reserved.oper via sta-&gt;sdata-&gt;link[link_id]. For stations on<br /> AP_VLAN interfaces (e.g. 4addr WDS clients), sta-&gt;sdata points to<br /> the VLAN sdata, whose link never participates in chanctx reservations.<br /> This leaves link-&gt;reserved.oper zero-initialized with chan == NULL,<br /> causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw()<br /> when accessing chandef-&gt;chan-&gt;band during CSA.<br /> <br /> Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata()<br /> before accessing link data.<br /> <br /> [also change sta-&gt;sdata in ARRAY_SIZE even if it doesn&amp;#39;t matter]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handler<br /> <br /> The ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler in<br /> bnxt_async_event_process() uses a firmware-supplied &amp;#39;type&amp;#39; field<br /> directly as an index into bp-&gt;bs_trace[] without bounds validation.<br /> <br /> The &amp;#39;type&amp;#39; field is a 16-bit value extracted from DMA-mapped completion<br /> ring memory that the NIC writes directly to host RAM. A malicious or<br /> compromised NIC can supply any value from 0 to 65535, causing an<br /> out-of-bounds access into kernel heap memory.<br /> <br /> The bnxt_bs_trace_check_wrap() call then dereferences bs_trace-&gt;magic_byte<br /> and writes to bs_trace-&gt;last_offset and bs_trace-&gt;wrapped, leading to<br /> kernel memory corruption or a crash.<br /> <br /> Fix by adding a bounds check and defining BNXT_TRACE_MAX as<br /> DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currently<br /> defined firmware trace types (0x0 through 0xc).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix use-after-free access to PTP clock<br /> <br /> PTP clock is registered on every opening of the interface and destroyed on<br /> every closing. However it may be accessed via get_ts_info ethtool call<br /> which is possible while the interface is just present in the kernel.<br /> <br /> BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426<br /> Read of size 4 at addr ffff8880194345cc by task syz.0.6/948<br /> <br /> CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:316 [inline]<br /> print_report+0x17f/0x496 mm/kasan/report.c:420<br /> kasan_report+0xd9/0x180 mm/kasan/report.c:524<br /> ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426<br /> gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349<br /> macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371<br /> __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558<br /> ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline]<br /> __dev_ethtool net/ethtool/ioctl.c:3017 [inline]<br /> dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095<br /> dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510<br /> sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215<br /> sock_ioctl+0x577/0x6d0 net/socket.c:1320<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:46 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> <br /> Allocated by task 457:<br /> kmalloc include/linux/slab.h:563 [inline]<br /> kzalloc include/linux/slab.h:699 [inline]<br /> ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235<br /> gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375<br /> macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920<br /> __dev_open+0x2ce/0x500 net/core/dev.c:1501<br /> __dev_change_flags+0x56a/0x740 net/core/dev.c:8651<br /> dev_change_flags+0x92/0x170 net/core/dev.c:8722<br /> do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833<br /> __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608<br /> rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655<br /> rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150<br /> netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0x14b/0x180 net/socket.c:730<br /> __sys_sendto+0x320/0x3b0 net/socket.c:2152<br /> __do_sys_sendto net/socket.c:2164 [inline]<br /> __se_sys_sendto net/socket.c:2160 [inline]<br /> __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160<br /> do_syscall_x64 arch/x86/entry/common.c:46 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 938:<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1729 [inline]<br /> slab_free_freelist_hook mm/slub.c:1755 [inline]<br /> slab_free mm/slub.c:3687 [inline]<br /> __kmem_cache_free+0xbc/0x320 mm/slub.c:3700<br /> device_release+0xa0/0x240 drivers/base/core.c:2507<br /> kobject_cleanup lib/kobject.c:681 [inline]<br /> kobject_release lib/kobject.c:712 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1cd/0x350 lib/kobject.c:729<br /> put_device+0x1b/0x30 drivers/base/core.c:3805<br /> ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391<br /> gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404<br /> macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966<br /> __dev_close_many+0x1b9/0x310 net/core/dev.c:1585<br /> __dev_close net/core/dev.c:1597 [inline]<br /> __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649<br /> dev_change_fl<br /> ---truncated---

immich is a high performance self-hosted photo and video management solution. Prior to version 2.6.0, the Immich application is vulnerable to credential disclosure when a user authenticates to a shared album. During the authentication process, the application transmits the album password within the URL query parameters in a GET request to /api/shared-links/me. This exposes the password in browser history, proxy and server logs, and referrer headers, allowing unintended disclosure of authentication credentials. The impact of this vulnerability is the potential compromise of shared album access and unauthorized exposure of sensitive user data. This issue has been patched in version 2.6.0.