Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: secure_seq: add back ports to TS offset<br /> <br /> This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")<br /> <br /> tcp_tw_recycle went away in 2017.<br /> <br /> Zhouyan Deng reported off-path TCP source port leakage via<br /> SYN cookie side-channel that can be fixed in multiple ways.<br /> <br /> One of them is to bring back TCP ports in TS offset randomization.<br /> <br /> As a bonus, we perform a single siphash() computation<br /> to provide both an ISN and a TS offset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix refcount bug and potential UAF in perf_mmap<br /> <br /> Syzkaller reported a refcount_t: addition on 0; use-after-free warning<br /> in perf_mmap.<br /> <br /> The issue is caused by a race condition between a failing mmap() setup<br /> and a concurrent mmap() on a dependent event (e.g., using output<br /> redirection).<br /> <br /> In perf_mmap(), the ring_buffer (rb) is allocated and assigned to<br /> event-&gt;rb with the mmap_mutex held. The mutex is then released to<br /> perform map_range().<br /> <br /> If map_range() fails, perf_mmap_close() is called to clean up.<br /> However, since the mutex was dropped, another thread attaching to<br /> this event (via inherited events or output redirection) can acquire<br /> the mutex, observe the valid event-&gt;rb pointer, and attempt to<br /> increment its reference count. If the cleanup path has already<br /> dropped the reference count to zero, this results in a<br /> use-after-free or refcount saturation warning.<br /> <br /> Fix this by extending the scope of mmap_mutex to cover the<br /> map_range() call. This ensures that the ring buffer initialization<br /> and mapping (or cleanup on failure) happens atomically effectively,<br /> preventing other threads from accessing a half-initialized or<br /> dying ring buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix memory allocation in nvme_pr_read_keys()<br /> <br /> nvme_pr_read_keys() takes num_keys from userspace and uses it to<br /> calculate the allocation size for rse via struct_size(). The upper<br /> limit is PR_KEYS_MAX (64K).<br /> <br /> A malicious or buggy userspace can pass a large num_keys value that<br /> results in a 4MB allocation attempt at most, causing a warning in<br /> the page allocator when the order exceeds MAX_PAGE_ORDER.<br /> <br /> To fix this, use kvzalloc() instead of kzalloc().<br /> <br /> This bug has the same reasoning and fix with the patch below:<br /> https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/<br /> <br /> Warning log:<br /> WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216<br /> Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d<br /> RSP: 0018:ffffc90000fcf450 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0<br /> RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0<br /> RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001<br /> R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000<br /> R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620<br /> FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486<br /> alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557<br /> ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598<br /> __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629<br /> __do_kmalloc_node mm/slub.c:5645 [inline]<br /> __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245<br /> blkdev_pr_read_keys block/ioctl.c:456 [inline]<br /> blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730<br /> blkdev_ioctl+0x299/0x700 block/ioctl.c:786<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583<br /> x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fb893d3108d<br /> Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d<br /> RDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_gate: snapshot parameters with RCU on replace<br /> <br /> The gate action can be replaced while the hrtimer callback or dump path is<br /> walking the schedule list.<br /> <br /> Convert the parameters to an RCU-protected snapshot and swap updates under<br /> tcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits<br /> the entry list, preserve the existing schedule so the effective state is<br /> unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration<br /> <br /> link_id is taken from the ML Reconfiguration element (control &amp; 0x000f),<br /> so it can be 0..15. link_removal_timeout[] has IEEE80211_MLD_MAX_NUM_LINKS<br /> (15) elements, so index 15 is out-of-bounds. Skip subelements with<br /> link_id &gt;= IEEE80211_MLD_MAX_NUM_LINKS to avoid a stack out-of-bounds<br /> write.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata<br /> <br /> We found an infinite loop bug in the ntfs3 file system that can lead to a<br /> Denial-of-Service (DoS) condition.<br /> <br /> A malformed NTFS image can cause an infinite loop when an attribute header<br /> indicates an empty run list, while directory entries reference it as<br /> containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way<br /> to represent an empty run list, and run_unpack() correctly handles this by<br /> checking if evcn + 1 equals svcn and returning early without parsing any run<br /> data. However, this creates a problem when there is metadata inconsistency,<br /> where the attribute header claims to be empty (evcn=-1) but the caller<br /> expects to read actual data. When run_unpack() immediately returns success<br /> upon seeing this condition, it leaves the runs_tree uninitialized with<br /> run-&gt;runs as a NULL. The calling function attr_load_runs_range() assumes<br /> that a successful return means that the runs were loaded and sets clen to 0,<br /> expecting the next run_lookup_entry() call to succeed. Because runs_tree<br /> remains uninitialized, run_lookup_entry() continues to fail, and the loop<br /> increments vcn by zero (vcn += 0), leading to an infinite loop.<br /> <br /> This patch adds a retry counter to detect when run_lookup_entry() fails<br /> consecutively after attr_load_runs_vcn(). If the run is still not found on<br /> the second attempt, it indicates corrupted metadata and returns -EINVAL,<br /> preventing the Denial-of-Service (DoS) vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ntfs3: check return value of indx_find to avoid infinite loop<br /> <br /> We found an infinite loop bug in the ntfs3 file system that can lead to a<br /> Denial-of-Service (DoS) condition.<br /> <br /> A malformed dentry in the ntfs3 filesystem can cause the kernel to hang<br /> during the lookup operations. By setting the HAS_SUB_NODE flag in an<br /> INDEX_ENTRY within a directory&amp;#39;s INDEX_ALLOCATION block and manipulating the<br /> VCN pointer, an attacker can cause the indx_find() function to repeatedly<br /> read the same block, allocating 4 KB of memory each time. The kernel lacks<br /> VCN loop detection and depth limits, causing memory exhaustion and an OOM<br /> crash.<br /> <br /> This patch adds a return value check for fnd_push() to prevent a memory<br /> exhaustion vulnerability caused by infinite loops. When the index exceeds the<br /> size of the fnd-&gt;nodes array, fnd_push() returns -EINVAL. The indx_find()<br /> function checks this return value and stops processing, preventing further<br /> memory allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST<br /> <br /> We found an infinite loop bug in the ntfs3 file system that can lead to a<br /> Denial-of-Service (DoS) condition.<br /> <br /> A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute<br /> indicates a zero data size while the driver allocates memory for it.<br /> <br /> When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set<br /> to zero, it still allocates memory because of al_aligned(0). This creates an<br /> inconsistent state where ni-&gt;attr_list.size is zero, but ni-&gt;attr_list.le is<br /> non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute<br /> list exists and enumerates only the primary MFT record. When it finds<br /> ATTR_LIST, the code reloads it and restarts the enumeration, repeating<br /> indefinitely. The mount operation never completes, hanging the kernel thread.<br /> <br /> This patch adds validation to ensure that data_size is non-zero before memory<br /> allocation. When a zero-sized ATTR_LIST is detected, the function returns<br /> -EINVAL, preventing a DoS vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix potential NULL pointer dereference in header processing<br /> <br /> If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),<br /> qp-&gt;rx_fpdu can be NULL. The error path in siw_tcp_rx_data()<br /> dereferences qp-&gt;rx_fpdu-&gt;more_ddp_segs without checking, which<br /> may lead to a NULL pointer deref. Only check more_ddp_segs when<br /> rx_fpdu is present.<br /> <br /> KASAN splat:<br /> [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7]<br /> [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50

beefree.io SDK is vulnerable to Stored XSS in Social Media icon URL parameter in email builder functionality. Malicious attacker can inject arbitrary HTML and JS into template, which will be rendered/executed when visiting preview page. However due to beefree&amp;#39;s Content Security Policy not all payloads will execute successfully.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> This issue has been fixed in version 3.47.0.

Missing Authorization vulnerability in WebberZone Contextual Related Posts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Contextual Related Posts: from n/a before 4.2.2.

The Yoast Duplicate Post plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the clone_bulk_action_handler() and republish_request() functions in all versions up to, and including, 4.5. This makes it possible for authenticated attackers, with Contributor-level access and above, to duplicate any post on the site including private, draft, and trashed posts they shouldn&amp;#39;t have access to. Additionally, attackers with Author-level access and above can use the Rewrite &amp; Republish feature to overwrite any published post with their own content.