Vulnerabilities

The Element Pack Addons for Elementor plugin for WordPress is vulnerable to arbitrary file reads in all versions up to, and including, 8.3.17 via the SVG widget and a lack of sufficient file validation in the 'render_svg' function. This makes it possible for authenticated attackers, with contributor-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information.

The Spam protection, Anti-Spam, FireWall by CleanTalk plugin for WordPress is vulnerable to unauthorized Arbitrary Plugin Installation due to an authorization bypass via reverse DNS (PTR record) spoofing on the 'checkWithoutToken' function in all versions up to, and including, 6.71. This makes it possible for unauthenticated attackers to install and activate arbitrary plugins which can be leveraged to achieve remote code execution if another vulnerable plugin is installed and activated. Note: This is only exploitable on sites with an invalid API key.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer<br /> <br /> The curr_xfer field is read by the IRQ handler without holding the lock<br /> to check if a transfer is in progress. When clearing curr_xfer in the<br /> combined sequence transfer loop, protect it with the spinlock to prevent<br /> a race with the interrupt handler.<br /> <br /> Protect the curr_xfer clearing at the exit path of<br /> tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race<br /> with the interrupt handler that reads this field.<br /> <br /> Without this protection, the IRQ handler could read a partially updated<br /> curr_xfer value, leading to NULL pointer dereference or use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue<br /> <br /> Commit 1767bb2d47b7 ("ipv6: mcast: Don&amp;#39;t hold RTNL for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this<br /> change triggered the following call trace on my BeagleBone Black board:<br /> WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: assertion failed at net/8021q/vlan_core.c (236)<br /> Modules linked in:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Hardware name: Generic AM33XX (Flattened Device Tree)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x28/0x2c<br /> show_stack from dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl from __warn+0xb8/0x11c<br /> __warn from warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt from vlan_for_each+0x120/0x124<br /> vlan_for_each from cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88<br /> __dev_mc_add from igmp6_group_added+0x84/0xec<br /> igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt from __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt from ret_fast_syscall+0x0/0x5<br /> <br /> This trace occurs because vlan_for_each() is called within<br /> cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.<br /> Since modifying vlan_for_each() to operate without the RTNL lock is not<br /> straightforward, and because ndo_set_rx_mode() is invoked both with and<br /> without the RTNL lock across different code paths, simply adding<br /> rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.<br /> <br /> To resolve this issue, we opt to execute the actual processing within<br /> a work queue, following the approach used by the icssg-prueth driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_u32: use skb_header_pointer_careful()<br /> <br /> skb_header_pointer() does not fully validate negative @offset values.<br /> <br /> Use skb_header_pointer_careful() instead.<br /> <br /> GangMin Kim provided a report and a repro fooling u32_classify():<br /> <br /> BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0<br /> net/sched/cls_u32.c:221

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix memory leak in smb2_open_file()<br /> <br /> Reproducer:<br /> <br /> 1. server: directories are exported read-only<br /> 2. client: mount -t cifs //${server_ip}/export /mnt<br /> 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. client: umount /mnt<br /> 5. client: sleep 1<br /> 6. client: modprobe -r cifs<br /> <br /> The error message is as follows:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Call Trace:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero<br /> <br /> The driver allocates arrays for ports, FDBs, and filter blocks using<br /> kcalloc() with ethsw-&gt;sw_attr.num_ifs as the element count. When the<br /> device reports zero interfaces (either due to hardware configuration<br /> or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)<br /> instead of NULL.<br /> <br /> Later in dpaa2_switch_probe(), the NAPI initialization unconditionally<br /> accesses ethsw-&gt;ports[0]-&gt;netdev, which attempts to dereference<br /> ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.<br /> <br /> Add a check to ensure num_ifs is greater than zero after retrieving<br /> device attributes. This prevents the zero-sized allocations and<br /> subsequent invalid pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra210-quad: Protect curr_xfer check in IRQ handler<br /> <br /> Now that all other accesses to curr_xfer are done under the lock,<br /> protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the<br /> spinlock. Without this protection, the following race can occur:<br /> <br /> CPU0 (ISR thread) CPU1 (timeout path)<br /> ---------------- -------------------<br /> if (!tqspi-&gt;curr_xfer)<br /> // sees non-NULL<br /> spin_lock()<br /> tqspi-&gt;curr_xfer = NULL<br /> spin_unlock()<br /> handle_*_xfer()<br /> spin_lock()<br /> t = tqspi-&gt;curr_xfer // NULL!<br /> ... t-&gt;len ... // NULL dereference!<br /> <br /> With this patch, all curr_xfer accesses are now properly synchronized.<br /> <br /> Although all accesses to curr_xfer are done under the lock, in<br /> tegra_qspi_isr_thread() it checks for NULL, releases the lock and<br /> reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().<br /> There is a potential for an update in between, which could cause a NULL<br /> pointer dereference.<br /> <br /> To handle this, add a NULL check inside the handlers after acquiring<br /> the lock. This ensures that if the timeout path has already cleared<br /> curr_xfer, the handler will safely return without dereferencing the<br /> NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Prevent excessive number of frames<br /> <br /> In this case, the user constructed the parameters with maxpacksize 40<br /> for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer<br /> size for each data URB is maxpacksize * packets, which in this example<br /> is 40 * 6 = 240; When the user performs a write operation to send audio<br /> data into the ALSA PCM playback stream, the calculated number of frames<br /> is packsize[0] * packets = 264, which exceeds the allocated URB buffer<br /> size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].<br /> <br /> Added a check for the number of single data URB frames when calculating<br /> the number of frames to prevent [1].<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506<br /> Call Trace:<br /> copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611<br /> prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix error recovery in macvlan_common_newlink()<br /> <br /> valis provided a nice repro to crash the kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> He also gave a very detailed analysis:<br /> <br /> <br /> <br /> The issue is triggered when a new macvlan link is created with<br /> MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or<br /> MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan<br /> port and register_netdevice() called from macvlan_common_newlink()<br /> fails (e.g. because of the invalid link name).<br /> <br /> In this case macvlan_hash_add_source is called from<br /> macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> This adds a reference to vlan to the port&amp;#39;s vlan_source_hash using<br /> macvlan_source_entry.<br /> <br /> vlan is a pointer to the priv data of the link that is being created.<br /> <br /> When register_netdevice() fails, the error is returned from<br /> macvlan_newlink() to rtnl_newlink_create():<br /> <br /> if (ops-&gt;newlink)<br /> err = ops-&gt;newlink(dev, &amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix PTP NULL pointer dereference during VSI rebuild<br /> <br /> Fix race condition where PTP periodic work runs while VSI is being<br /> rebuilt, accessing NULL vsi-&gt;rx_rings.<br /> <br /> The sequence was:<br /> 1. ice_ptp_prepare_for_reset() cancels PTP work<br /> 2. ice_ptp_rebuild() immediately queues PTP work<br /> 3. VSI rebuild happens AFTER ice_ptp_rebuild()<br /> 4. PTP work runs and accesses NULL vsi-&gt;rx_rings<br /> <br /> Fix: Keep PTP work cancelled during rebuild, only queue it after<br /> VSI rebuild completes in ice_rebuild().<br /> <br /> Added ice_ptp_queue_work() helper function to encapsulate the logic<br /> for queuing PTP work, ensuring it&amp;#39;s only queued when PTP is supported<br /> and the state is ICE_PTP_READY.<br /> <br /> Error log:<br /> [ 121.392544] ice 0000:60:00.1: PTP reset successful<br /> [ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 121.392712] #PF: supervisor read access in kernel mode<br /> [ 121.392720] #PF: error_code(0x0000) - not-present page<br /> [ 121.392727] PGD 0<br /> [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)<br /> [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]<br /> [ 121.393042] Call Trace:<br /> [ 121.393047] <br /> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]<br /> [ 121.393202] kthread_worker_fn+0xa2/0x260<br /> [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]<br /> [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [ 121.393371] kthread+0x10d/0x230<br /> [ 121.393382] ? __pfx_kthread+0x10/0x10<br /> [ 121.393393] ret_from_fork+0x273/0x2b0<br /> [ 121.393407] ? __pfx_kthread+0x10/0x10<br /> [ 121.393417] ret_from_fork_asm+0x1a/0x30<br /> [ 121.393432]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> linkwatch: use __dev_put() in callers to prevent UAF<br /> <br /> After linkwatch_do_dev() calls __dev_put() to release the linkwatch<br /> reference, the device refcount may drop to 1. At this point,<br /> netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an<br /> empty list and returns without blocking), wait for the refcount to<br /> become 1 via netdev_wait_allrefs_any(), and then free the device<br /> via kobject_put().<br /> <br /> This creates a use-after-free when __linkwatch_run_queue() tries to<br /> call netdev_unlock_ops() on the already-freed device.<br /> <br /> Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in<br /> netdev_run_todo() before kobject_put() would not work, because<br /> netdev_lock_ops() is conditional - it only locks when<br /> netdev_need_ops_lock() returns true. If the device doesn&amp;#39;t require<br /> ops_lock, linkwatch won&amp;#39;t hold any lock, and netdev_run_todo()<br /> acquiring the lock won&amp;#39;t provide synchronization.<br /> <br /> Fix this by moving __dev_put() from linkwatch_do_dev() to its<br /> callers. The device reference logically pairs with de-listing the<br /> device, so it&amp;#39;s reasonable for the caller that did the de-listing<br /> to release it. This allows placing __dev_put() after all device<br /> accesses are complete, preventing UAF.<br /> <br /> The bug can be reproduced by adding mdelay(2000) after<br /> linkwatch_do_dev() in __linkwatch_run_queue(), then running:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================