| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in moodle. This formula injection vulnerability occurs when data fields are exported without proper escaping. A remote attacker could exploit this by providing malicious data that, when exported and opened in a spreadsheet, allows arbitrary formulas to execute. This can lead to compromised data integrity and unintended operations within the spreadsheet. |
| A flaw was found in moodle. This vulnerability, known as Cross-Site Scripting (XSS), occurs due to insufficient checks on user-provided data in the formula editor's arithmetic expression fields. A remote attacker could inject malicious code into these fields. When other users view these expressions, the malicious code would execute in their web browsers, potentially compromising their data or leading to unauthorized actions. |
| A flaw was found in Moodle. This cross-site scripting (XSS) vulnerability, caused by improper sanitization of AI prompt responses, allows attackers to inject malicious HTML or script into web pages. When other users view these compromised pages, their sessions could be stolen, or the user interface could be manipulated. |
| A flaw was found in Moodle. This authentication bypass vulnerability allows suspended users to authenticate through the Learning Tools Interoperability (LTI) Provider. The issue arises from the LTI authentication handlers failing to enforce the user's suspension status, enabling unauthorized access to the system. This can lead to information disclosure or other unauthorized actions by users who should be restricted. |
| Dell Secure Connect Gateway (SCG) 5.0 Appliance and Application, version(s) versions 5.26 to 5.30, contain(s) an Execution with Unnecessary Privileges vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges. |
| A vulnerability exists in PX Enterprise whereby sensitive information may be logged under specific conditions. |
| A floating-point exception (FPE) in the flow.column_stack component of OneFlow v0.9.0 allows attackers to cause a Denial of Service (DoS) via a crafted input. |
| An input validation vulnerability in the flow.arange() component of OneFlow v0.9.0 allows attackers to cause a Denial of Service (DoS) via a crafted input. |
| Unverified Password Change vulnerability in Progress MOVEit Transfer on Windows (REST API modules).This issue affects MOVEit Transfer: from 2023.1.0 before 2023.1.3, from 2023.0.0 before 2023.0.8, from 2022.1.0 before 2022.1.11, from 2022.0.0 before 2022.0.10. |
| Redlib is an alternative private front-end to Reddit. A vulnerability has been identified in Redlib where an attacker can cause a denial-of-service (DOS) condition by submitting a specially crafted base2048-encoded DEFLATE decompression bomb to the restore_preferences form. This leads to excessive memory consumption and potential system instability, which can be exploited to disrupt Redlib instances. This vulnerability is fixed in 0.36.0. |
| Knowage is an open source analytics and business intelligence suite. Prior to version 8.1.37, there is a blind server-side request forgery vulnerability. The vulnerability allows attackers to send requests to arbitrary hosts/paths. Since the attacker is not able to read the response, the impact of this vulnerability is limited. However, an attacker should be able to leverage this vulnerability to scan the internal network. This issue has been patched in version 8.1.37. |
| e-Learning PHP Script 0.1.0 contains a SQL injection vulnerability in the search functionality that allows attackers to manipulate database queries through unvalidated user input. Attackers can inject malicious SQL code in the 'search' parameter to potentially extract, modify, or access sensitive database information. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: release path before initializing extent tree in btrfs_read_locked_inode()
In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()
while holding a path with a read locked leaf from a subvolume tree, and
btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can
trigger reclaim.
This can create a circular lock dependency which lockdep warns about with
the following splat:
[6.1433] ======================================================
[6.1574] WARNING: possible circular locking dependency detected
[6.1583] 6.18.0+ #4 Tainted: G U
[6.1591] ------------------------------------------------------
[6.1599] kswapd0/117 is trying to acquire lock:
[6.1606] ffff8d9b6333c5b8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0
[6.1625]
but task is already holding lock:
[6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60
[6.1646]
which lock already depends on the new lock.
[6.1657]
the existing dependency chain (in reverse order) is:
[6.1667]
-> #2 (fs_reclaim){+.+.}-{0:0}:
[6.1677] fs_reclaim_acquire+0x9d/0xd0
[6.1685] __kmalloc_cache_noprof+0x59/0x750
[6.1694] btrfs_init_file_extent_tree+0x90/0x100
[6.1702] btrfs_read_locked_inode+0xc3/0x6b0
[6.1710] btrfs_iget+0xbb/0xf0
[6.1716] btrfs_lookup_dentry+0x3c5/0x8e0
[6.1724] btrfs_lookup+0x12/0x30
[6.1731] lookup_open.isra.0+0x1aa/0x6a0
[6.1739] path_openat+0x5f7/0xc60
[6.1746] do_filp_open+0xd6/0x180
[6.1753] do_sys_openat2+0x8b/0xe0
[6.1760] __x64_sys_openat+0x54/0xa0
[6.1768] do_syscall_64+0x97/0x3e0
[6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[6.1784]
-> #1 (btrfs-tree-00){++++}-{3:3}:
[6.1794] lock_release+0x127/0x2a0
[6.1801] up_read+0x1b/0x30
[6.1808] btrfs_search_slot+0x8e0/0xff0
[6.1817] btrfs_lookup_inode+0x52/0xd0
[6.1825] __btrfs_update_delayed_inode+0x73/0x520
[6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120
[6.1842] btrfs_log_inode+0x608/0x1aa0
[6.1849] btrfs_log_inode_parent+0x249/0xf80
[6.1857] btrfs_log_dentry_safe+0x3e/0x60
[6.1865] btrfs_sync_file+0x431/0x690
[6.1872] do_fsync+0x39/0x80
[6.1879] __x64_sys_fsync+0x13/0x20
[6.1887] do_syscall_64+0x97/0x3e0
[6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[6.1903]
-> #0 (&delayed_node->mutex){+.+.}-{3:3}:
[6.1913] __lock_acquire+0x15e9/0x2820
[6.1920] lock_acquire+0xc9/0x2d0
[6.1927] __mutex_lock+0xcc/0x10a0
[6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0
[6.1944] btrfs_evict_inode+0x20b/0x4b0
[6.1952] evict+0x15a/0x2f0
[6.1958] prune_icache_sb+0x91/0xd0
[6.1966] super_cache_scan+0x150/0x1d0
[6.1974] do_shrink_slab+0x155/0x6f0
[6.1981] shrink_slab+0x48e/0x890
[6.1988] shrink_one+0x11a/0x1f0
[6.1995] shrink_node+0xbfd/0x1320
[6.1002] balance_pgdat+0x67f/0xc60
[6.1321] kswapd+0x1dc/0x3e0
[6.1643] kthread+0xff/0x240
[6.1965] ret_from_fork+0x223/0x280
[6.1287] ret_from_fork_asm+0x1a/0x30
[6.1616]
other info that might help us debug this:
[6.1561] Chain exists of:
&delayed_node->mutex --> btrfs-tree-00 --> fs_reclaim
[6.1503] Possible unsafe locking scenario:
[6.1110] CPU0 CPU1
[6.1411] ---- ----
[6.1707] lock(fs_reclaim);
[6.1998] lock(btrfs-tree-00);
[6.1291] lock(fs_reclaim);
[6.1581] lock(&del
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix NULL dereference on devlink_alloc() failure
devlink_alloc() may return NULL on allocation failure, but
prestera_devlink_alloc() unconditionally calls devlink_priv() on
the returned pointer.
This leads to a NULL pointer dereference if devlink allocation fails.
Add a check for a NULL devlink pointer and return NULL early to avoid
the crash. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: prevent pcp corruption with SMP=n
The kernel test robot has reported:
BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28
lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0
CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470
Call Trace:
<IRQ>
__dump_stack (lib/dump_stack.c:95)
dump_stack_lvl (lib/dump_stack.c:123)
dump_stack (lib/dump_stack.c:130)
spin_dump (kernel/locking/spinlock_debug.c:71)
do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)
_raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)
__free_frozen_pages (mm/page_alloc.c:2973)
___free_pages (mm/page_alloc.c:5295)
__free_pages (mm/page_alloc.c:5334)
tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)
? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)
? rcu_core (kernel/rcu/tree.c:?)
rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)
rcu_core_si (kernel/rcu/tree.c:2879)
handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)
__irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)
irq_exit_rcu (kernel/softirq.c:741)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)
</IRQ>
<TASK>
RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)
free_pcppages_bulk (mm/page_alloc.c:1494)
drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)
__drain_all_pages (mm/page_alloc.c:2731)
drain_all_pages (mm/page_alloc.c:2747)
kcompactd (mm/compaction.c:3115)
kthread (kernel/kthread.c:465)
? __cfi_kcompactd (mm/compaction.c:3166)
? __cfi_kthread (kernel/kthread.c:412)
ret_from_fork (arch/x86/kernel/process.c:164)
? __cfi_kthread (kernel/kthread.c:412)
ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
</TASK>
Matthew has analyzed the report and identified that in drain_page_zone()
we are in a section protected by spin_lock(&pcp->lock) and then get an
interrupt that attempts spin_trylock() on the same lock. The code is
designed to work this way without disabling IRQs and occasionally fail the
trylock with a fallback. However, the SMP=n spinlock implementation
assumes spin_trylock() will always succeed, and thus it's normally a
no-op. Here the enabled lock debugging catches the problem, but otherwise
it could cause a corruption of the pcp structure.
The problem has been introduced by commit 574907741599 ("mm/page_alloc:
leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme
recognizes the need for disabling IRQs to prevent nesting spin_trylock()
sections on SMP=n, but the need to prevent the nesting in spin_lock() has
not been recognized. Fix it by introducing local wrappers that change the
spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places
that do spin_lock(&pcp->lock).
[vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven] |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: release path before iget_failed() in btrfs_read_locked_inode()
In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to
the 'out' label with a path that has a read locked leaf and then we call
iget_failed(). This can result in a ABBA deadlock, since iget_failed()
triggers inode eviction and that causes the release of the delayed inode,
which must lock the delayed inode's mutex, and a task updating a delayed
inode starts by taking the node's mutex and then modifying the inode's
subvolume btree.
Syzbot reported the following lockdep splat for this:
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
btrfs-cleaner/8725 is trying to acquire lock:
ffff0000d6826a48 (&delayed_node->mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
but task is already holding lock:
ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{4:4}:
__lock_release kernel/locking/lockdep.c:5574 [inline]
lock_release+0x198/0x39c kernel/locking/lockdep.c:5889
up_read+0x24/0x3c kernel/locking/rwsem.c:1632
btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169
btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [inline]
btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133
btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395
__btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032
btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [inline]
__btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141
__btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176
btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219
flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828
do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158
btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226
process_one_work+0x7e8/0x155c kernel/workqueue.c:3263
process_scheduled_works kernel/workqueue.c:3346 [inline]
worker_thread+0x958/0xed8 kernel/workqueue.c:3427
kthread+0x5fc/0x75c kernel/kthread.c:463
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844
-> #0 (&delayed_node->mutex){+.+.}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237
lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868
__mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598
__mutex_lock kernel/locking/mutex.c:760 [inline]
mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812
__btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [inline]
btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326
btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587
evict+0x414/0x928 fs/inode.c:810
iput_final fs/inode.c:1914 [inline]
iput+0x95c/0xad4 fs/inode.c:1966
iget_failed+0xec/0x134 fs/bad_inode.c:248
btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101
btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837
btrfs_run_defrag_inode fs/btrfs/defrag.c:237 [inline]
btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation
Make sure to drop the reference taken when looking up the crossbar
platform device during am335x route allocation. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv
mlx5e_priv is an unstable structure that can be memset(0) if profile
attaching fails.
Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a
valid netdev.
On mlx5e_remove: Check validity of priv->profile, before attempting
to cleanup any resources that might be not there.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due
to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev
Error: mlx5_core: Failed setting eswitch to offloads.
dmesg:
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12
workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12
mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000370
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100
RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286
RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0
RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10
R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0
R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400
FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0
Call Trace:
<TASK>
mlx5e_remove+0x57/0x110
device_release_driver_internal+0x19c/0x200
bus_remove_device+0xc6/0x130
device_del+0x160/0x3d0
? devl_param_driverinit_value_get+0x2d/0x90
mlx5_detach_device+0x89/0xe0
mlx5_unload_one_devl_locked+0x3a/0x70
mlx5_devlink_reload_down+0xc8/0x220
devlink_reload+0x7d/0x260
devlink_nl_reload_doit+0x45b/0x5a0
genl_family_rcv_msg_doit+0xe8/0x140 |
| HelloWeb 2.0 contains an arbitrary file download vulnerability that allows remote attackers to download system files by manipulating filepath and filename parameters. Attackers can send crafted GET requests to download.asp with directory traversal to access sensitive configuration and system files. |
| RM Downloader 2.50.60 contains a local buffer overflow vulnerability in the 'Load' parameter that allows attackers to execute arbitrary code by overwriting memory. Attackers can craft a malicious payload with an egg hunter technique to bypass memory protections and execute commands like launching calc.exe. |
