Vulnerabilities

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Narnoo Wordpress developer Narnoo Commerce Manager allows Reflected XSS.This issue affects Narnoo Commerce Manager: from n/a through 1.6.0.

The The Paid Membership Subscriptions – Effortless Memberships, Recurring Payments & Content Restriction plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 2.13.0. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check the validity of nr_words in bpf_iter_bits_new()<br /> <br /> Check the validity of nr_words in bpf_iter_bits_new(). Without this<br /> check, when multiplication overflow occurs for nr_bits (e.g., when<br /> nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur<br /> due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008).<br /> <br /> Fix it by limiting the maximum value of nr_words to 511. The value is<br /> derived from the current implementation of BPF memory allocator. To<br /> ensure compatibility if the BPF memory allocator&amp;#39;s size limitation<br /> changes in the future, use the helper bpf_mem_alloc_check_size() to<br /> check whether nr_bytes is too larger. And return -E2BIG instead of<br /> -ENOMEM for oversized nr_bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()<br /> <br /> bpf_iter_bits_destroy() uses "kit-&gt;nr_bits bit to kit-&gt;nr_bits instead of setting<br /> kit-&gt;nr_bits to zero when the iteration completes in<br /> bpf_iter_bits_next(). In addition, use "!nr_bits || bits &gt;= nr_bits" to<br /> check whether the iteration is complete and still use "nr_bits &gt; 64" to<br /> indicate whether bits are dynamically allocated. The "!nr_bits" check is<br /> necessary because bpf_iter_bits_new() may fail before setting<br /> kit-&gt;nr_bits, and this condition will stop the iteration early instead<br /> of accessing the zeroed or freed kit-&gt;bits.<br /> <br /> Considering the initial value of kit-&gt;bits is -1 and the type of<br /> kit-&gt;nr_bits is unsigned int, change the type of kit-&gt;nr_bits to int.<br /> The potential overflow problem will be handled in the following patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()<br /> <br /> The following race condition could trigger a NULL pointer dereference:<br /> <br /> sock_map_link_detach(): sock_map_link_update_prog():<br /> mutex_lock(&amp;sockmap_mutex);<br /> ...<br /> sockmap_link-&gt;map = NULL;<br /> mutex_unlock(&amp;sockmap_mutex);<br /> mutex_lock(&amp;sockmap_mutex);<br /> ...<br /> sock_map_prog_link_lookup(sockmap_link-&gt;map);<br /> mutex_unlock(&amp;sockmap_mutex);<br /> <br /> <br /> Fix it by adding a NULL pointer check. In this specific case, it makes<br /> no sense to update a link which is being released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix crash when config small gso_max_size/gso_ipv4_max_size<br /> <br /> Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow<br /> in sk_dst_gso_max_size(), which may trigger a BUG_ON crash,<br /> because sk-&gt;sk_gso_max_size would be much bigger than device limits.<br /> Call Trace:<br /> tcp_write_xmit<br /> tso_segs = tcp_init_tso_segs(skb, mss_now);<br /> tcp_set_skb_tso_segs<br /> tcp_skb_pcount_set<br /> // skb-&gt;len = 524288, mss_now = 8<br /> // u16 tso_segs = 524288/8 = 65535 -&gt; 0<br /> tso_segs = DIV_ROUND_UP(skb-&gt;len, mss_now)<br /> BUG_ON(!tso_segs)<br /> Add check for the minimum value of gso_max_size and gso_ipv4_max_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs<br /> <br /> Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.<br /> <br /> __hci_cmd_sync_sk() returns NULL if a command returns a status event.<br /> However, it also returns NULL where an opcode doesn&amp;#39;t exist in the<br /> hci_cc table because hci_cmd_complete_evt() assumes status = skb-&gt;data[0]<br /> for unknown opcodes.<br /> This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as<br /> there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes<br /> status = skb-&gt;data[0].<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]<br /> CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: hci7 hci_power_on<br /> RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138<br /> Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78<br /> RSP: 0018:ffff888120bafac8 EFLAGS: 00010212<br /> RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040<br /> RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4<br /> RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054<br /> R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000<br /> FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline]<br /> hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline]<br /> hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline]<br /> hci_init_sync net/bluetooth/hci_sync.c:4742 [inline]<br /> hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]<br /> hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994<br /> hci_dev_do_open net/bluetooth/hci_core.c:483 [inline]<br /> hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015<br /> process_one_work kernel/workqueue.c:3267 [inline]<br /> process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348<br /> worker_thread+0x91f/0xe50 kernel/workqueue.c:3429<br /> kthread+0x2cb/0x360 kernel/kthread.c:388<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()<br /> <br /> I got a syzbot report without a repro [1] crashing in nf_send_reset6()<br /> <br /> I think the issue is that dev-&gt;hard_header_len is zero, and we attempt<br /> later to push an Ethernet header.<br /> <br /> Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.<br /> <br /> [1]<br /> <br /> skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun<br /> kernel BUG at net/core/skbuff.c:206 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]<br /> RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216<br /> Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3<br /> RSP: 0018:ffffc900045269b0 EFLAGS: 00010282<br /> RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800<br /> RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000<br /> RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc<br /> R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140<br /> R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c<br /> FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_push+0xe5/0x100 net/core/skbuff.c:2636<br /> eth_header+0x38/0x1f0 net/ethernet/eth.c:83<br /> dev_hard_header include/linux/netdevice.h:3208 [inline]<br /> nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358<br /> nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]<br /> br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424<br /> __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562<br /> __netif_receive_skb_one_core net/core/dev.c:5666 [inline]<br /> __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781<br /> netif_receive_skb_internal net/core/dev.c:5867 [inline]<br /> netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926<br /> tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550<br /> tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007<br /> tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053<br /> new_sync_write fs/read_write.c:590 [inline]<br /> vfs_write+0xa6d/0xc90 fs/read_write.c:683<br /> ksys_write+0x183/0x2b0 fs/read_write.c:736<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fdbeeb7d1ff<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48<br /> RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff<br /> RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8<br /> RBP: 00007fdbeebf12be R08: 0000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: Fix use-after-free in get_info()<br /> <br /> ip6table_nat module unload has refcnt warning for UAF. call trace is:<br /> <br /> WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80<br /> Modules linked in: ip6table_nat(-)<br /> CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:module_put+0x6f/0x80<br /> Call Trace:<br /> <br /> get_info+0x128/0x180<br /> do_ip6t_get_ctl+0x6a/0x430<br /> nf_getsockopt+0x46/0x80<br /> ipv6_getsockopt+0xb9/0x100<br /> rawv6_getsockopt+0x42/0x190<br /> do_sock_getsockopt+0xaa/0x180<br /> __sys_getsockopt+0x70/0xc0<br /> __x64_sys_getsockopt+0x20/0x30<br /> do_syscall_64+0xa2/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Concurrent execution of module unload and get_info() trigered the warning.<br /> The root cause is as follows:<br /> <br /> cpu0 cpu1<br /> module_exit<br /> //mod-&gt;state = MODULE_STATE_GOING<br /> ip6table_nat_exit<br /> xt_unregister_template<br /> kfree(t)<br /> //removed from templ_list<br /> getinfo()<br /> t = xt_find_table_lock<br /> list_for_each_entry(tmpl, &amp;xt_templates[af]...)<br /> if (strcmp(tmpl-&gt;name, name))<br /> continue; //table not found<br /> try_module_get<br /> list_for_each_entry(t, &amp;xt_net-&gt;tables[af]...)<br /> return t; //not get refcnt<br /> module_put(t-&gt;me) //uaf<br /> unregister_pernet_subsys<br /> //remove table from xt_net list<br /> <br /> While xt_table module was going away and has been removed from<br /> xt_templates list, we couldnt get refcnt of xt_table-&gt;me. Check<br /> module in xt_net-&gt;tables list re-traversal to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()<br /> <br /> This was found by a static analyzer.<br /> We should not forget the trailing zero after copy_from_user()<br /> if we will further do some string operations, sscanf() in this<br /> case. Adding a trailing zero will ensure that the function<br /> performs properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: Fix use-after-free while sending the offloading packet<br /> <br /> KASAN reports the following UAF. The metadata_dst, which is used to<br /> store the SCI value for macsec offload, is already freed by<br /> metadata_dst_free() in macsec_free_netdev(), while driver still use it<br /> for sending the packet.<br /> <br /> To fix this issue, dst_release() is used instead to release<br /> metadata_dst. So it is not freed instantly in macsec_free_netdev() if<br /> still referenced by skb.<br /> <br /> BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]<br /> Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714<br /> [...]<br /> Workqueue: mld mld_ifc_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xc1/0x600<br /> kasan_report+0xab/0xe0<br /> mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]<br /> dev_hard_start_xmit+0x120/0x530<br /> sch_direct_xmit+0x149/0x11e0<br /> __qdisc_run+0x3ad/0x1730<br /> __dev_queue_xmit+0x1196/0x2ed0<br /> vlan_dev_hard_start_xmit+0x32e/0x510 [8021q]<br /> dev_hard_start_xmit+0x120/0x530<br /> __dev_queue_xmit+0x14a7/0x2ed0<br /> macsec_start_xmit+0x13e9/0x2340<br /> dev_hard_start_xmit+0x120/0x530<br /> __dev_queue_xmit+0x14a7/0x2ed0<br /> ip6_finish_output2+0x923/0x1a70<br /> ip6_finish_output+0x2d7/0x970<br /> ip6_output+0x1ce/0x3a0<br /> NF_HOOK.constprop.0+0x15f/0x190<br /> mld_sendpack+0x59a/0xbd0<br /> mld_ifc_work+0x48a/0xa80<br /> process_one_work+0x5aa/0xe50<br /> worker_thread+0x79c/0x1290<br /> kthread+0x28f/0x350<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> Allocated by task 3922:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0x77/0x90<br /> __kmalloc_noprof+0x188/0x400<br /> metadata_dst_alloc+0x1f/0x4e0<br /> macsec_newlink+0x914/0x1410<br /> __rtnl_newlink+0xe08/0x15b0<br /> rtnl_newlink+0x5f/0x90<br /> rtnetlink_rcv_msg+0x667/0xa80<br /> netlink_rcv_skb+0x12c/0x360<br /> netlink_unicast+0x551/0x770<br /> netlink_sendmsg+0x72d/0xbd0<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x52e/0x6a0<br /> ___sys_sendmsg+0xeb/0x170<br /> __sys_sendmsg+0xb5/0x140<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 4011:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x50<br /> poison_slab_object+0x10c/0x190<br /> __kasan_slab_free+0x11/0x30<br /> kfree+0xe0/0x290<br /> macsec_free_netdev+0x3f/0x140<br /> netdev_run_todo+0x450/0xc70<br /> rtnetlink_rcv_msg+0x66f/0xa80<br /> netlink_rcv_skb+0x12c/0x360<br /> netlink_unicast+0x551/0x770<br /> netlink_sendmsg+0x72d/0xbd0<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x52e/0x6a0<br /> ___sys_sendmsg+0xeb/0x170<br /> __sys_sendmsg+0xb5/0x140<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix out-of-bounds write in trie_get_next_key()<br /> <br /> trie_get_next_key() allocates a node stack with size trie-&gt;max_prefixlen,<br /> while it writes (trie-&gt;max_prefixlen + 1) nodes to the stack when it has<br /> full paths from the root to leaves. For example, consider a trie with<br /> max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...<br /> 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with<br /> .prefixlen = 8 make 9 nodes be written on the node stack with size 8.