Vulnerabilities

Mattermost versions 9.5.x

The Masteriyo LMS – eLearning and Online Course Builder for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the question's content parameter in all versions up to, and including, 1.13.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with student-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Masteriyo LMS – eLearning and Online Course Builder for WordPress plugin for WordPress is vulnerable to unauthorized user profile modification due to missing authorization checks on the /wp-json/masteriyo/v1/users/$id REST API endpoint in all versions up to, and including, 1.13.3. This makes it possible for authenticated attackers, with student-level access and above, to modify the roles of arbitrary users. As a result, attackers can escalate their privileges to the Administrator and demote existing administrators to students.

A vulnerability, which was classified as problematic, was found in LinZhaoguan pb-cms up to 2.0.1. Affected is an unknown function of the file /admin#themes of the component Theme Management Module. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

There is a command injection vulnerability in ZTE MF258 Pro product. Due to insufficient validation of Ping Diagnosis interface parameter, an authenticated attacker could use the vulnerability to execute arbitrary commands.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: don&amp;#39;t allow user copy for unprivileged device<br /> <br /> UBLK_F_USER_COPY requires userspace to call write() on ublk char<br /> device for filling request buffer, and unprivileged device can&amp;#39;t<br /> be trusted.<br /> <br /> So don&amp;#39;t allow user copy for unprivileged device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()<br /> <br /> Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in<br /> kunit test") fixed the use-after-free error, but introduced below<br /> memory leaks by removing necessary vcap_free_rule(), add it to fix it.<br /> <br /> unreferenced object 0xffffff80ca58b700 (size 192):<br /> comm "kunit_try_catch", pid 1215, jiffies 4294898264<br /> hex dump (first 32 bytes):<br /> 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d...<br /> 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................<br /> backtrace (crc 9c09c3fe):<br /> [] kmemleak_alloc+0x34/0x40<br /> [] __kmalloc_cache_noprof+0x26c/0x2f4<br /> [] vcap_alloc_rule+0x3cc/0x9c4<br /> [] vcap_api_encode_rule_test+0x1ac/0x16b0<br /> [] kunit_try_run_case+0x13c/0x3ac<br /> [] kunit_generic_run_threadfn_adapter+0x80/0xec<br /> [] kthread+0x2e8/0x374<br /> [] ret_from_fork+0x10/0x20<br /> unreferenced object 0xffffff80cc0b0400 (size 64):<br /> comm "kunit_try_catch", pid 1215, jiffies 4294898265<br /> hex dump (first 32 bytes):<br /> 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X.....<br /> 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9...............<br /> backtrace (crc daf014e9):<br /> [] kmemleak_alloc+0x34/0x40<br /> [] __kmalloc_cache_noprof+0x26c/0x2f4<br /> [] vcap_rule_add_key+0x2cc/0x528<br /> [] vcap_api_encode_rule_test+0x224/0x16b0<br /> [] kunit_try_run_case+0x13c/0x3ac<br /> [] kunit_generic_run_threadfn_adapter+0x80/0xec<br /> [] kthread+0x2e8/0x374<br /> [] ret_from_fork+0x10/0x20<br /> unreferenced object 0xffffff80cc0b0700 (size 64):<br /> comm "kunit_try_catch", pid 1215, jiffies 4294898265<br /> hex dump (first 32 bytes):<br /> 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X.....<br /> 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: setup queue -&gt;tag_set before initializing hctx<br /> <br /> Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx")<br /> needs to check queue mapping via tag set in hctx&amp;#39;s cpuhp handler.<br /> <br /> However, q-&gt;tag_set may not be setup yet when the cpuhp handler is<br /> enabled, then kernel oops is triggered.<br /> <br /> Fix the issue by setup queue tag_set before initializing hctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race<br /> <br /> We&amp;#39;re seeing crashes from rq_qos_wake_function that look like this:<br /> <br /> BUG: unable to handle page fault for address: ffffafe180a40084<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0<br /> Oops: Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40<br /> Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00<br /> RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011<br /> RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084<br /> RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011<br /> R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002<br /> R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003<br /> FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> try_to_wake_up+0x5a/0x6a0<br /> rq_qos_wake_function+0x71/0x80<br /> __wake_up_common+0x75/0xa0<br /> __wake_up+0x36/0x60<br /> scale_up.part.0+0x50/0x110<br /> wb_timer_fn+0x227/0x450<br /> ...<br /> <br /> So rq_qos_wake_function() calls wake_up_process(data-&gt;task), which calls<br /> try_to_wake_up(), which faults in raw_spin_lock_irqsave(&amp;p-&gt;pi_lock).<br /> <br /> p comes from data-&gt;task, and data comes from the waitqueue entry, which<br /> is stored on the waiter&amp;#39;s stack in rq_qos_wait(). Analyzing the core<br /> dump with drgn, I found that the waiter had already woken up and moved<br /> on to a completely unrelated code path, clobbering what was previously<br /> data-&gt;task. Meanwhile, the waker was passing the clobbered garbage in<br /> data-&gt;task to wake_up_process(), leading to the crash.<br /> <br /> What&amp;#39;s happening is that in between rq_qos_wake_function() deleting the<br /> waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding<br /> that it already got a token and returning. The race looks like this:<br /> <br /> rq_qos_wait() rq_qos_wake_function()<br /> ==============================================================<br /> prepare_to_wait_exclusive()<br /> data-&gt;got_token = true;<br /> list_del_init(&amp;curr-&gt;entry);<br /> if (data.got_token)<br /> break;<br /> finish_wait(&amp;rqw-&gt;wait, &amp;data.wq);<br /> ^- returns immediately because<br /> list_empty_careful(&amp;wq_entry-&gt;entry)<br /> is true<br /> ... return, go do something else ...<br /> wake_up_process(data-&gt;task)<br /> (NO LONGER VALID!)-^<br /> <br /> Normally, finish_wait() is supposed to synchronize against the waker.<br /> But, as noted above, it is returning immediately because the waitqueue<br /> entry has already been removed from the waitqueue.<br /> <br /> The bug is that rq_qos_wake_function() is accessing the waitqueue entry<br /> AFTER deleting it. Note that autoremove_wake_function() wakes the waiter<br /> and THEN deletes the waitqueue entry, which is the proper order.<br /> <br /> Fix it by swapping the order. We also need to use<br /> list_del_init_careful() to match the list_empty_careful() in<br /> finish_wait().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix mptcp DSS corruption due to large pmtu xmit<br /> <br /> Syzkaller was able to trigger a DSS corruption:<br /> <br /> TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695<br /> Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff<br /> RSP: 0018:ffffc90000006db8 EFLAGS: 00010246<br /> RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00<br /> RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0<br /> RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8<br /> R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5<br /> FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> move_skbs_to_msk net/mptcp/protocol.c:811 [inline]<br /> mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854<br /> subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490<br /> tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283<br /> tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237<br /> tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915<br /> tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350<br /> ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233<br /> NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314<br /> NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314<br /> __netif_receive_skb_one_core net/core/dev.c:5662 [inline]<br /> __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775<br /> process_backlog+0x662/0x15b0 net/core/dev.c:6107<br /> __napi_poll+0xcb/0x490 net/core/dev.c:6771<br /> napi_poll net/core/dev.c:6840 [inline]<br /> net_rx_action+0x89b/0x1240 net/core/dev.c:6962<br /> handle_softirqs+0x2c5/0x980 kernel/softirq.c:554<br /> do_softirq+0x11b/0x1e0 kernel/softirq.c:455<br /> <br /> <br /> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]<br /> __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451<br /> dev_queue_xmit include/linux/netdevice.h:3094 [inline]<br /> neigh_hh_output include/net/neighbour.h:526 [inline]<br /> neigh_output include/net/neighbour.h:540 [inline]<br /> ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236<br /> ip_local_out net/ipv4/ip_output.c:130 [inline]<br /> __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536<br /> __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]<br /> tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]<br /> tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752<br /> __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015<br /> tcp_push_pending_frames include/net/tcp.h:2107 [inline]<br /> tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]<br /> tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239<br /> tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915<br /> sk_backlog_rcv include/net/sock.h:1113 [inline]<br /> __release_sock+0x214/0x350 net/core/sock.c:3072<br /> release_sock+0x61/0x1f0 net/core/sock.c:3626<br /> mptcp_push_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow<br /> <br /> Syzkaller reported this splat:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881<br /> Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662<br /> <br /> CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881<br /> mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]<br /> mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572<br /> mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603<br /> genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]<br /> netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357<br /> netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg net/socket.c:744 [inline]<br /> ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607<br /> ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661<br /> __sys_sendmsg+0x117/0x1f0 net/socket.c:2690<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]<br /> __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386<br /> do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> RIP: 0023:0xf7fe4579<br /> Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00<br /> RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172<br /> RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> Allocated by task 5387:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394<br /> kmalloc_noprof include/linux/slab.h:878 [inline]<br /> kzalloc_noprof include/linux/slab.h:1014 [inline]<br /> subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803<br /> subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956<br /> __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]<br /> tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167<br /> mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764<br /> __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592<br /> mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642<br /> mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]<br /> mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943<br /> mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777<br /> process_one_work+0x958/0x1b30 kernel/workqueue.c:3229<br /> process_scheduled_works kernel/workqueue.c:3310 [inline]<br /> worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/ke<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix user-after-free from session log off<br /> <br /> There is racy issue between smb2 session log off and smb2 session setup.<br /> It will cause user-after-free from session log off.<br /> This add session_lock when setting SMB2_SESSION_EXPIRED and referece<br /> count to session struct not to free session while it is being used.