| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| CMSimple 5.15 contains a remote command execution vulnerability that allows authenticated attackers to modify file extensions and upload malicious PHP files. Attackers can append ',php' to Extensions_userfiles and upload a shell script to the media directory to execute arbitrary code on the server. |
| Okta Java Management SDK facilitates interactions with the Okta management API. In versions 21.0.0 through 24.0.0, specific multithreaded implementations may encounter memory issues as threads are not properly cleaned up after requests are completed. Over time, this can degrade performance and availability in long-running applications and may result in a denial-of-service condition under sustained load. In addition to using the affected versions, users may be at risk if they are implementing a long-running application using the ApiClient in a multi-threaded manner. This issue is fixed in version 24.0.1. |
| In Open5GS 2.7.6, AMF crashes when receiving an abnormal NGSetupRequest message, resulting in denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]
[<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]
[<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]
[<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342
[<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553
[<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147
[<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082
[<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540
[<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
[<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
[<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
[<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]
[<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734
[<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482
[<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
[<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622
[<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]
[<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]
[<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648
[<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================
Kernel uses tcindex_change() to change an existing
filter properties.
Yet the problem is that, during the process of changing,
if `old_r` is retrieved from `p->perfect`, then
kernel uses tcindex_alloc_perfect_hash() to newly
allocate filter results, uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure, which triggers the above memory leak.
To be more specific, there are only two source for the `old_r`,
according to the tcindex_lookup(). `old_r` is retrieved from
`p->perfect`, or `old_r` is retrieved from `p->h`.
* If `old_r` is retrieved from `p->perfect`, kernel uses
tcindex_alloc_perfect_hash() to newly allocate the
filter results. Then `r` is assigned with `cp->perfect + handle`,
which is newly allocated. So condition `old_r && old_r != r` is
true in this situation, and kernel uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure
* If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL
according to the tcindex_lookup(). Considering that `cp->h`
is directly copied from `p->h` and `p->perfect` is NULL,
`r` is assigned with `tcindex_lookup(cp, handle)`, whose value
should be the same as `old_r`, so condition `old_r && old_r != r`
is false in this situation, kernel ignores using
tcindex_filter_result_init() to clear the old filter result.
So only when `old_r` is retrieved from `p->perfect` does kernel use
tcindex_filter_result_init() to clear the old filter result, which
triggers the above memory leak.
Considering that there already exists a tc_filter_wq workqueue
to destroy the old tcindex_d
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
integrity: Fix memory leakage in keyring allocation error path
Key restriction is allocated in integrity_init_keyring(). However, if
keyring allocation failed, it is not freed, causing memory leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix memory leak in set_mempolicy_home_node system call
When encountering any vma in the range with policy other than MPOL_BIND or
MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on
the policy just allocated with mpol_dup().
This allows arbitrary users to leak kernel memory. |
| In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
In crb_acpi_add(), we get the TPM2 table to retrieve information
like start method, and then assign them to the priv data, so the
TPM2 table is not used after the init, should be freed, call
acpi_put_table() to fix the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hinic: fix the issue of CMDQ memory leaks
When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is
not released correctly. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic at
once. |
| Uncontrolled resource consumption in Windows Remote Procedure Call allows an unauthorized attacker to deny service over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability()
Fixed coverity issue with resource leaks at variable "fw" going out of
scope leaks the storage it points to mt7921_check_offload_capability().
Addresses-Coverity-ID: 1527806 ("Resource leaks") |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/hpre - fix resource leak in remove process
In hpre_remove(), when the disable operation of qm sriov failed,
the following logic should continue to be executed to release the
remaining resources that have been allocated, instead of returning
directly, otherwise there will be resource leakage. |
| In the Linux kernel, the following vulnerability has been resolved:
media: mdp3: Fix resource leaks in of_find_device_by_node
Use put_device to release the object get through of_find_device_by_node,
avoiding resource leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: fix mem leak in capture user mappings
This commit fixes a memory leak caused when clearing the user_mappings
info when a new context is opened immediately after user_mapping is
captured and a hard reset is performed. |
| In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
When insert and remove the orangefs module, there are memory leaked
as below:
unreferenced object 0xffff88816b0cc000 (size 2048):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f
[<00000000e5a0085b>] 0xffffffffa02780f9
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Use the golbal variable as the buffer rather than dynamic allocate to
slove the problem. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: Fix possible memory leak if device_add() fails
If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to give up the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp(). |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak when build ntlmssp negotiate blob failed
There is a memory leak when mount cifs:
unreferenced object 0xffff888166059600 (size 448):
comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s)
hex dump (first 32 bytes):
fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000060609a61>] mempool_alloc+0xe1/0x260
[<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60
[<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460
[<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0
[<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480
[<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410
[<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0
[<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0
[<000000006cbc43d9>] mount_get_conns+0x7a/0x730
[<000000005922d816>] cifs_mount+0x103/0xd10
[<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90
[<0000000078034979>] smb3_get_tree+0x1d5/0x300
[<000000004371f980>] vfs_get_tree+0x41/0xf0
[<00000000b670d8a7>] path_mount+0x9b3/0xdd0
[<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0
[<000000009404c3b9>] do_syscall_64+0x35/0x80
When build ntlmssp negotiate blob failed, the session setup request
should be freed. |
| In the Linux kernel, the following vulnerability has been resolved:
cassini: Fix a memory leak in the error handling path of cas_init_one()
cas_saturn_firmware_init() allocates some memory using vmalloc(). This
memory is freed in the .remove() function but not it the error handling
path of the probe.
Add the missing vfree() to avoid a memory leak, should an error occur. |
| In the Linux kernel, the following vulnerability has been resolved:
net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6
When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just
exits the function. This ends up causing a memory-leak:
unreferenced object 0xffff0000281a8200 (size 2496):
comm "softirq", pid 0, jiffies 4295174684
hex dump (first 32 bytes):
7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................
0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............
backtrace (crc 5ebdbe15):
kmemleak_alloc+0x44/0xe0
kmem_cache_alloc_noprof+0x248/0x470
sk_prot_alloc+0x48/0x120
sk_clone_lock+0x38/0x3b0
inet_csk_clone_lock+0x34/0x150
tcp_create_openreq_child+0x3c/0x4a8
tcp_v6_syn_recv_sock+0x1c0/0x620
tcp_check_req+0x588/0x790
tcp_v6_rcv+0x5d0/0xc18
ip6_protocol_deliver_rcu+0x2d8/0x4c0
ip6_input_finish+0x74/0x148
ip6_input+0x50/0x118
ip6_sublist_rcv+0x2fc/0x3b0
ipv6_list_rcv+0x114/0x170
__netif_receive_skb_list_core+0x16c/0x200
netif_receive_skb_list_internal+0x1f0/0x2d0
This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when
exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need
to be called. They make sure the newsk will end up being correctly
free'd.
tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit
label that takes care of things. So, this patch here makes sure
tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar
error-handling and thus fixes the leak for TCP-AO. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: cpumap: Fix memory leak in cpu_map_update_elem
Syzkaller reported a memory leak as follows:
BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........
00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......
backtrace:
[<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff110001198ef528 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff1100010fd93d68 (size 8):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace:
[<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170
[<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
In the cpu_map_update_elem flow, when kthread_stop is called before
calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit
of kthread has been set by kthread_stop, the threadfn of rcpu->kthread
will never be executed, and rcpu->refcnt will never be 0, which will
lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be
released.
Calling kthread_stop before executing kthread's threadfn will return
-EINTR. We can complete the release of memory resources in this state. |
