Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV<br /> <br /> RLCG Register Access is a way for virtual functions to safely access GPU<br /> registers in a virtualized environment., including TLB flushes and<br /> register reads. When multiple threads or VFs try to access the same<br /> registers simultaneously, it can lead to race conditions. By using the<br /> RLCG interface, the driver can serialize access to the registers. This<br /> means that only one thread can access the registers at a time,<br /> preventing conflicts and ensuring that operations are performed<br /> correctly. Additionally, when a low-priority task holds a mutex that a<br /> high-priority task needs, ie., If a thread holding a spinlock tries to<br /> acquire a mutex, it can lead to priority inversion. register access in<br /> amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.<br /> <br /> The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being<br /> called, which attempts to acquire the mutex. This function is invoked<br /> from amdgpu_sriov_wreg, which in turn is called from<br /> gmc_v11_0_flush_gpu_tlb.<br /> <br /> The [ BUG: Invalid wait context ] indicates that a thread is trying to<br /> acquire a mutex while it is in a context that does not allow it to sleep<br /> (like holding a spinlock).<br /> <br /> Fixes the below:<br /> <br /> [ 253.013423] =============================<br /> [ 253.013434] [ BUG: Invalid wait context ]<br /> [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE<br /> [ 253.013464] -----------------------------<br /> [ 253.013475] kworker/0:1/10 is trying to lock:<br /> [ 253.013487] ffff9f30542e3cf8 (&amp;adev-&gt;virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]<br /> [ 253.013815] other info that might help us debug this:<br /> [ 253.013827] context-{4:4}<br /> [ 253.013835] 3 locks held by kworker/0:1/10:<br /> [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680<br /> [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&amp;wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680<br /> [ 253.013905] #2: ffff9f3054281838 (&amp;adev-&gt;gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu]<br /> [ 253.014154] stack backtrace:<br /> [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14<br /> [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024<br /> [ 253.014224] Workqueue: events work_for_cpu_fn<br /> [ 253.014241] Call Trace:<br /> [ 253.014250] <br /> [ 253.014260] dump_stack_lvl+0x9b/0xf0<br /> [ 253.014275] dump_stack+0x10/0x20<br /> [ 253.014287] __lock_acquire+0xa47/0x2810<br /> [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 253.014321] lock_acquire+0xd1/0x300<br /> [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]<br /> [ 253.014562] ? __lock_acquire+0xa6b/0x2810<br /> [ 253.014578] __mutex_lock+0x85/0xe20<br /> [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]<br /> [ 253.014782] ? sched_clock_noinstr+0x9/0x10<br /> [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 253.014808] ? local_clock_noinstr+0xe/0xc0<br /> [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]<br /> [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 253.015029] mutex_lock_nested+0x1b/0x30<br /> [ 253.015044] ? mutex_lock_nested+0x1b/0x30<br /> [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]<br /> [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu]<br /> [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu]<br /> [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu]<br /> [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu]<br /> [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu]<br /> [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu]<br /> [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu]<br /> [ 253.0170<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: use aead_request_free to match aead_request_alloc<br /> <br /> Use aead_request_free() instead of kfree() to properly free memory<br /> allocated by aead_request_alloc(). This ensures sensitive crypto data<br /> is zeroed before being freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Fix off-by-one error in build_prologue()<br /> <br /> Vincent reported that running BPF progs with tailcalls on LoongArch<br /> causes kernel hard lockup. Debugging the issues shows that the JITed<br /> image missing a jirl instruction at the end of the epilogue.<br /> <br /> There are two passes in JIT compiling, the first pass set the flags and<br /> the second pass generates JIT code based on those flags. With BPF progs<br /> mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the<br /> first pass and then generates N+1 insns in the second pass. This makes<br /> epilogue_offset off by one and we will jump to some unexpected insn and<br /> cause lockup. Fix this by inserting a nop insn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix NULL dereferences in ef100_process_design_param()<br /> <br /> Since cited commit, ef100_probe_main() and hence also<br /> ef100_check_design_params() run before efx-&gt;net_dev is created;<br /> consequently, we cannot netif_set_tso_max_size() or _segs() at this<br /> point.<br /> Move those netif calls to ef100_probe_netdev(), and also replace<br /> netif_err within the design params code with pci_err.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix OOB read when checking dotdot dir<br /> <br /> Mounting a corrupted filesystem with directory which contains &amp;#39;.&amp;#39; dir<br /> entry with rec_len == block size results in out-of-bounds read (later<br /> on, when the corrupted directory is removed).<br /> <br /> ext4_empty_dir() assumes every ext4 directory contains at least &amp;#39;.&amp;#39;<br /> and &amp;#39;..&amp;#39; as directory entries in the first data block. It first loads<br /> the &amp;#39;.&amp;#39; dir entry, performs sanity checks by calling ext4_check_dir_entry()<br /> and then uses its rec_len member to compute the location of &amp;#39;..&amp;#39; dir<br /> entry (in ext4_next_entry). It assumes the &amp;#39;..&amp;#39; dir entry fits into the<br /> same data block.<br /> <br /> If the rec_len of &amp;#39;.&amp;#39; is precisely one block (4KB), it slips through the<br /> sanity checks (it is considered the last directory entry in the data<br /> block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the<br /> memory slot allocated to the data block. The following call to<br /> ext4_check_dir_entry() on new value of de then dereferences this pointer<br /> which results in out-of-bounds mem access.<br /> <br /> Fix this by extending __ext4_check_dir_entry() to check for &amp;#39;.&amp;#39; dir<br /> entries that reach the end of data block. Make sure to ignore the phony<br /> dir entries for checksum (by checking name_len for non-zero).<br /> <br /> Note: This is reported by KASAN as use-after-free in case another<br /> structure was recently freed from the slot past the bound, but it is<br /> really an OOB read.<br /> <br /> This issue was found by syzkaller tool.<br /> <br /> Call Trace:<br /> [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710<br /> [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375<br /> [ 38.595158]<br /> [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1<br /> [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 38.595304] Call Trace:<br /> [ 38.595308] <br /> [ 38.595311] dump_stack_lvl+0xa7/0xd0<br /> [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0<br /> [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710<br /> [ 38.595349] print_report+0xaa/0x250<br /> [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710<br /> [ 38.595368] ? kasan_addr_to_slab+0x9/0x90<br /> [ 38.595378] kasan_report+0xab/0xe0<br /> [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710<br /> [ 38.595400] __ext4_check_dir_entry+0x67e/0x710<br /> [ 38.595410] ext4_empty_dir+0x465/0x990<br /> [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10<br /> [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10<br /> [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0<br /> [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10<br /> [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10<br /> [ 38.595478] ? down_write+0xdb/0x140<br /> [ 38.595487] ? __pfx_down_write+0x10/0x10<br /> [ 38.595497] ext4_rmdir+0xee/0x140<br /> [ 38.595506] vfs_rmdir+0x209/0x670<br /> [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190<br /> [ 38.595529] do_rmdir+0x363/0x3c0<br /> [ 38.595537] ? __pfx_do_rmdir+0x10/0x10<br /> [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0<br /> [ 38.595561] __x64_sys_unlinkat+0xf0/0x130<br /> [ 38.595570] do_syscall_64+0x5b/0x180<br /> [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e

A vulnerability classified as critical was found in SourceCodester Web-based Pharmacy Product Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /add-product.php. The manipulation of the argument Avatar leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

The Coupon Affiliates – Affiliate Plugin for WooCommerce plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the commission_summary parameter in all versions up to, and including, .6.3.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

The MapPress Maps for WordPress plugin before 2.94.10 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

Insecure default settings have been found in recorder products provided by Yokogawa Electric Corporation. The default setting of the authentication function is disabled on the affected products. Therefore, when connected to a network with default settings, anyone can access all functions related to settings and operations. As a result, an attacker can illegally manipulate and configure important data such as measured values and settings.<br /> This issue affects GX10 / GX20 / GP10 / GP20 Paperless Recorders: R5.04.01 or earlier; GM Data Acquisition System: R5.05.01 or earlier; DX1000 / DX2000 / DX1000N Paperless Recorders: R4.21 or earlier; FX1000 Paperless Recorders: R1.31 or earlier; μR10000 / μR20000 Chart Recorders: R1.51 or earlier; MW100 Data Acquisition Units: All versions; DX1000T / DX2000T Paperless Recorders: All versions; CX1000 / CX2000 Paperless Recorders: All versions.

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Pantherius Modal Survey allows Reflected XSS.This issue affects Modal Survey: from n/a through 2.0.2.0.1.

Path Traversal: &amp;#39;.../...//&amp;#39; vulnerability in ThimPress Ivy School allows PHP Local File Inclusion.This issue affects Ivy School: from n/a through 1.6.0.

Improper Neutralization of Special Elements used in an SQL Command (&amp;#39;SQL Injection&amp;#39;) vulnerability in Pantherius Modal Survey.This issue affects Modal Survey: from n/a through 2.0.2.0.1.