Vulnerabilities

The SKT Skill Bar plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the `chart_size` attribute of the `skillwrapper` shortcode in all versions up to, and including, 2.6. This is due to insufficient input sanitization and output escaping on the `chart_size` attribute, which is concatenated directly into an inline `` block. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The ShopLentor plugin for WordPress is vulnerable to arbitrary function execution via the woolentoropt/v1/custom-action REST API endpoint in all versions up to, and including, 3.3.7. This is due to the handle_action() method passing user-supplied input directly to call_user_func() without an allowlist of permitted callbacks. This makes it possible for authenticated attackers, with Administrator-level access and above, to execute arbitrary PHP callable functions via the 'callback' parameter.

The Material Dashboard plugin for WordPress is vulnerable to unauthorized access and modification of data due to missing capability checks on the amd_ajax_target_task_manager() function in all versions up to, and including, 1.4.10. This makes it possible for unauthenticated attackers to enumerate all scheduled tasks (potentially exposing PII), execute arbitrary tasks, and delete any task via the public_amd_ajax_handler AJAX action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix sk_dst_cache double-free in xfrm_user_policy()<br /> <br /> xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(),<br /> i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with<br /> rcu_dereference_protected(), stores NULL and dst_release()s the old dst.<br /> That is only safe if no other thread modifies sk_dst_cache concurrently.<br /> <br /> For a connected UDP socket that does not hold: the transmit fast path<br /> (udp_sendmsg -&gt; sk_dst_check -&gt; sk_dst_reset) resets the cache locklessly<br /> with an atomic xchg(). A per-socket policy change racing a send can make<br /> both sides observe the same old dst and each dst_release() it, dropping<br /> the socket&amp;#39;s single reference twice and freeing the xfrm_dst bundle while<br /> it is still referenced:<br /> <br /> BUG: KASAN: slab-use-after-free in dst_release<br /> Write of size 4 at addr ffff88801897b6c0 by task exploit/155<br /> Call Trace:<br /> ...<br /> dst_release (... ./include/linux/rcuref.h:109)<br /> xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053)<br /> do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347)<br /> ip_setsockopt (net/ipv4/ip_sockglue.c:1417)<br /> do_sock_setsockopt (net/socket.c:2368)<br /> __sys_setsockopt (net/socket.c:2393)<br /> __x64_sys_setsockopt (net/socket.c:2396)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> Reachable by an unprivileged user via a user+network namespace.<br /> <br /> Use the atomic sk_dst_reset() so the cache is cleared and released with a<br /> single xchg(): whichever side wins releases the dst once, the other sees<br /> NULL and does nothing. Behaviour is otherwise unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst()<br /> <br /> On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst()<br /> releases the device reference with netdev_put() but leaves<br /> xdst-&gt;u.dst.dev set. dst_destroy() later calls netdev_put(dst-&gt;dev)<br /> again, so the same net_device reference is released twice, underflowing<br /> its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for<br /> to become free").<br /> <br /> Clear xdst-&gt;u.dst.dev after the netdev_put(), the same way the XFRM<br /> device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in<br /> net/xfrm/xfrm_device.c NULL -&gt;dev when releasing the reference on error.<br /> <br /> ref_tracker: reference already released.<br /> ref_tracker: allocated in:<br /> xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86)<br /> ...<br /> udpv6_sendmsg (net/ipv6/udp.c:1696)<br /> ...<br /> ref_tracker: freed in:<br /> xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90)<br /> ...<br /> WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780<br /> dst_destroy (net/core/dst.c:115)<br /> rcu_core<br /> handle_softirqs<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: tear down new links on vif update error path<br /> <br /> When ieee80211_vif_update_links() adds new links it allocates a link<br /> container for each and calls ieee80211_link_init() (which registers the<br /> per-link debugfs files with file-&gt;private_data pointing into the container)<br /> and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails,<br /> the error path restores the old pointers and jumps to &amp;#39;free&amp;#39;, which frees<br /> the new containers but never removes their debugfs entries or stops the<br /> links. The debugfs files survive with file-&gt;private_data dangling at the<br /> freed container, so a later open()+read() (e.g. link-1/txpower)<br /> dereferences freed memory in ieee80211_if_read_link(), a use-after-free.<br /> <br /> The removal path already dismantles links correctly via<br /> ieee80211_tear_down_links(), which removes each link&amp;#39;s keys and debugfs<br /> entries and calls ieee80211_link_stop(); the add path on the error branch<br /> does not. Commit be1ba9ed221f ("wifi: mac80211: avoid weird state in error<br /> path") hardened this same error path for the link-removal case<br /> (new_links == 0) but left the newly-added links&amp;#39; teardown unaddressed.<br /> <br /> drv_change_vif_links() can fail at runtime on MLO drivers (internal<br /> allocation / queue / firmware command failures).<br /> <br /> Remove the new links&amp;#39; debugfs entries and stop them before freeing.<br /> <br /> BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127)<br /> Read of size 8 at addr ffff888011290000 by task exploit/145<br /> Call Trace:<br /> ...<br /> ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127)<br /> short_proxy_read (fs/debugfs/file.c:373)<br /> vfs_read (fs/read_write.c:572)<br /> ksys_read (fs/read_write.c:716)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> ...<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a<br /> RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127)<br /> Kernel panic - not syncing: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix NVM tag length underflow in TLV parser<br /> <br /> In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is<br /> "while (idx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: tcp: fix double sock release on batch realloc<br /> <br /> bpf_iter_tcp_batch() releases the current batch via<br /> bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites<br /> each slot with the socket cookie, then grows the batch. cur_sk/end_sk<br /> are kept for bpf_iter_tcp_resume(), but on realloc failure the function<br /> returns ERR_PTR() before resume runs, leaving cur_sk

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: initialize extack in nh_res_bucket_migrate()<br /> <br /> nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to<br /> call_nexthop_res_bucket_notifiers(). When<br /> nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns<br /> -ENOMEM), the error is propagated back before any notifier sets<br /> extack._msg, and the error path formats the stale pointer with<br /> pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE<br /> this dereferences uninitialized stack memory:<br /> <br /> Oops: general protection fault, probably for non-canonical address ...<br /> KASAN: maybe wild-memory-access in range [...]<br /> RIP: 0010:string (lib/vsprintf.c:730)<br /> vsnprintf (lib/vsprintf.c:2945)<br /> _printk (kernel/printk/printk.c:2504)<br /> nh_res_bucket_migrate (net/ipv4/nexthop.c:1816)<br /> nh_res_table_upkeep (net/ipv4/nexthop.c:1866)<br /> rtm_new_nexthop (net/ipv4/nexthop.c:3323)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1900)<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Zero-initialize extack so _msg is NULL on error paths that never set it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: check skb_pull_data() return in gtp1u_send_echo_resp()<br /> <br /> gtp1u_send_echo_resp() ignores skb_pull_data()&amp;#39;s return value. Its<br /> caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr +<br /> gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For<br /> a 16-19 byte echo request the pull fails and returns NULL without<br /> advancing skb-&gt;data; execution continues, and the following skb_push()<br /> plus the IP header pushed by iptunnel_xmit() move skb-&gt;data below<br /> skb-&gt;head, tripping skb_under_panic().<br /> <br /> Fix it by dropping the packet when skb_pull_data() fails.<br /> <br /> skbuff: skb_under_panic: ...<br /> kernel BUG at net/core/skbuff.c:214!<br /> Call Trace:<br /> skb_push (net/core/skbuff.c:2648)<br /> iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82)<br /> gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920)<br /> udp_queue_rcv_one_skb (net/ipv4/udp.c:2388)<br /> ...<br /> Kernel panic - not syncing: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate compound request size before reading StructureSize2<br /> <br /> When ksmbd validates a compound (chained) SMB2 request,<br /> ksmbd_smb2_check_message() reads pdu-&gt;StructureSize2 without first<br /> checking that the compound element is large enough to contain it.<br /> StructureSize2 is a 2-byte field at offset 64<br /> (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element.<br /> <br /> The compound-walking logic only guarantees that a full 64-byte SMB2<br /> header is present for the trailing element: when NextCommand is 0, len is<br /> reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A<br /> remote client can craft a compound request whose last element has exactly<br /> 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte<br /> past the receive buffer, producing a slab-out-of-bounds read.<br /> <br /> BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)<br /> Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14<br /> The buggy address is located 172 bytes inside of allocated 173-byte region<br /> Workqueue: ksmbd-io handle_ksmbd_work<br /> Call Trace:<br /> ...<br /> kasan_report (mm/kasan/report.c:595)<br /> ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)<br /> handle_ksmbd_work (fs/smb/server/server.c:119)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3397)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)<br /> <br /> Reject any compound element that is too small to hold StructureSize2<br /> before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert<br /> <br /> xfrm_hash_rebuild()&amp;#39;s first loop preallocates the bins/chains the reinsert<br /> loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or<br /> fail. But its guard is inverted: it skips policies with prefixlen