Vulnerabilities

Cross-Site Request Forgery (CSRF) vulnerability in victoracano Cazamba allows Reflected XSS.This issue affects Cazamba: from n/a through 1.2.

Server-Side Request Forgery (SSRF) vulnerability in SuitePlugins Video & Photo Gallery for Ultimate Member allows Server Side Request Forgery.This issue affects Video & Photo Gallery for Ultimate Member: from n/a through 1.1.2.

Missing Authorization vulnerability in WPFactory EAN for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects EAN for WooCommerce: from n/a through 5.3.5.

Missing Authorization vulnerability in EnvoThemes Envo Multipurpose allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Envo Multipurpose: from n/a through 1.1.6.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in CodeTrendy Power Mag allows DOM-Based XSS.This issue affects Power Mag: from n/a through 1.1.5.

Cross-Site Request Forgery (CSRF) vulnerability in WPDeveloper Secret Meta allows Reflected XSS.This issue affects Secret Meta: from n/a through 1.2.1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers<br /> <br /> Other, non DAI copier widgets could have the same stream name (sname) as<br /> the ALH copier and in that case the copier-&gt;data is NULL, no alh_data is<br /> attached, which could lead to NULL pointer dereference.<br /> We could check for this NULL pointer in sof_ipc4_prepare_copier_module()<br /> and avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()<br /> will miscalculate the ALH device count, causing broken audio.<br /> <br /> The correct fix is to harden the matching logic by making sure that the<br /> 1. widget is a DAI widget - so dai = w-&gt;private is valid<br /> 2. the dai (and thus the copier) is ALH copier

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/code-patching: Disable KASAN report during patching via temporary mm<br /> <br /> Erhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:<br /> <br /> [ 12.028126] ==================================================================<br /> [ 12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0<br /> [ 12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1<br /> <br /> [ 12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.13.0-P9-dirty #3<br /> [ 12.028408] Tainted: [T]=RANDSTRUCT<br /> [ 12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV<br /> [ 12.028500] Call Trace:<br /> [ 12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)<br /> [ 12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708<br /> [ 12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300<br /> [ 12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370<br /> [ 12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40<br /> [ 12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0<br /> [ 12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210<br /> [ 12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590<br /> [ 12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0<br /> [ 12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0<br /> [ 12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930<br /> [ 12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280<br /> [ 12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370<br /> [ 12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00<br /> [ 12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40<br /> [ 12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610<br /> [ 12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280<br /> [ 12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8<br /> [ 12.029608] NIP: 00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000<br /> [ 12.029660] REGS: c000000008dbfe80 TRAP: 3000 Tainted: G T (6.13.0-P9-dirty)<br /> [ 12.029735] MSR: 900000000280f032 CR: 42004848 XER: 00000000<br /> [ 12.029855] IRQMASK: 0<br /> GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005<br /> GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008<br /> GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000<br /> GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90<br /> GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80<br /> GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8<br /> GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580<br /> [ 12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8<br /> [ 12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8<br /> [ 12.030405] --- interrupt: 3000<br /> [ 12.030444] ==================================================================<br /> <br /> Commit c28c15b6d28a ("powerpc/code-patching: Use temporary mm for<br /> Radix MMU") is inspired from x86 but unlike x86 is doesn&amp;#39;t disable<br /> KASAN reports during patching. This wasn&amp;#39;t a problem at the begining<br /> because __patch_mem() is not instrumented.<br /> <br /> Commit 465cabc97b42 ("powerpc/code-patching: introduce<br /> patch_instructions()") use copy_to_kernel_nofault() to copy several<br /> instructions at once. But when using temporary mm the destination is<br /> not regular kernel memory but a kind of kernel-like memory located<br /> in user address space. <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: optee: Fix supplicant wait loop<br /> <br /> OP-TEE supplicant is a user-space daemon and it&amp;#39;s possible for it<br /> be hung or crashed or killed in the middle of processing an OP-TEE<br /> RPC call. It becomes more complicated when there is incorrect shutdown<br /> ordering of the supplicant process vs the OP-TEE client application which<br /> can eventually lead to system hang-up waiting for the closure of the<br /> client application.<br /> <br /> Allow the client process waiting in kernel for supplicant response to<br /> be killed rather than indefinitely waiting in an unkillable state. Also,<br /> a normal uninterruptible wait should not have resulted in the hung-task<br /> watchdog getting triggered, but the endless loop would.<br /> <br /> This fixes issues observed during system reboot/shutdown when supplicant<br /> got hung for some reason or gets crashed/killed which lead to client<br /> getting hung in an unkillable state. It in turn lead to system being in<br /> hung up state requiring hard power off/on to recover.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()<br /> <br /> KMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The<br /> cause of the issue was that eth_skb_pkt_type() accessed skb&amp;#39;s data<br /> that didn&amp;#39;t contain an Ethernet header. This occurs when<br /> bpf_prog_test_run_xdp() passes an invalid value as the user_data<br /> argument to bpf_test_init().<br /> <br /> Fix this by returning an error when user_data is less than ETH_HLEN in<br /> bpf_test_init(). Additionally, remove the check for "if (user_size &gt;<br /> size)" as it is unnecessary.<br /> <br /> [1]<br /> BUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]<br /> BUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165<br /> eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]<br /> eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165<br /> __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635<br /> xdp_recv_frames net/bpf/test_run.c:272 [inline]<br /> xdp_test_run_batch net/bpf/test_run.c:361 [inline]<br /> bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390<br /> bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318<br /> bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371<br /> __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777<br /> __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]<br /> __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864<br /> x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> free_pages_prepare mm/page_alloc.c:1056 [inline]<br /> free_unref_page+0x156/0x1320 mm/page_alloc.c:2657<br /> __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838<br /> bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]<br /> ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235<br /> bpf_map_free kernel/bpf/syscall.c:838 [inline]<br /> bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310<br /> worker_thread+0xedf/0x1550 kernel/workqueue.c:3391<br /> kthread+0x535/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: allow small head cache usage with large MAX_SKB_FRAGS values<br /> <br /> Sabrina reported the following splat:<br /> <br /> WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0<br /> Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48<br /> RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e<br /> RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6<br /> RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c<br /> R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168<br /> R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007<br /> FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> gro_cells_init+0x1ba/0x270<br /> xfrm_input_init+0x4b/0x2a0<br /> xfrm_init+0x38/0x50<br /> ip_rt_init+0x2d7/0x350<br /> ip_init+0xf/0x20<br /> inet_init+0x406/0x590<br /> do_one_initcall+0x9d/0x2e0<br /> do_initcalls+0x23b/0x280<br /> kernel_init_freeable+0x445/0x490<br /> kernel_init+0x20/0x1d0<br /> ret_from_fork+0x46/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> irq event stamp: 584330<br /> hardirqs last enabled at (584338): [] __up_console_sem+0x77/0xb0<br /> hardirqs last disabled at (584345): [] __up_console_sem+0x5c/0xb0<br /> softirqs last enabled at (583242): [] netlink_insert+0x14d/0x470<br /> softirqs last disabled at (583754): [] netif_napi_add_weight_locked+0x77d/0xba0<br /> <br /> on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)<br /> is smaller than GRO_MAX_HEAD.<br /> <br /> Such built additionally contains the revert of the single page frag cache<br /> so that napi_get_frags() ends up using the page frag allocator, triggering<br /> the splat.<br /> <br /> Note that the underlying issue is independent from the mentioned<br /> revert; address it ensuring that the small head cache will fit either TCP<br /> and GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()<br /> to select kmalloc() usage for any allocation fitting such cache.

A vulnerability, which was classified as critical, has been found in Codezips Gym Management System 1.0. This issue affects some unknown processing of the file /dashboard/admin/over_month.php. The manipulation of the argument mm leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.