| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A memory leak in the headless API for StructuredContents in Liferay Portal 7.4.0 through 7.4.3.119, and older unsupported versions, and Liferay DXP 2024.Q1.1 through 2024.Q1.5, 2023.Q4.0 through 2024.Q4.10, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions allows an attacker to cause server unavailability (denial of service) via repeatedly calling the API endpoint. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
When the nvif_vmm_type is invalid, we will return error directly
without freeing the args in nvif_vmm_ctor(), which leading a memory
leak. Fix it by setting the ret -EINVAL and goto done. |
| In the Linux kernel, the following vulnerability has been resolved:
efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths
When processing mount options, efivarfs allocates efivarfs_fs_info (sfi)
early in fs_context initialization. However, sfi is associated with the
superblock and typically freed when the superblock is destroyed. If the
fs_context is released (final put) before fill_super is called—such as
on error paths or during reconfiguration—the sfi structure would leak,
as ownership never transfers to the superblock.
Implement the .free callback in efivarfs_context_ops to ensure any
allocated sfi is properly freed if the fs_context is torn down before
fill_super, preventing this memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
media: imagination: fix a potential memory leak in e5010_probe()
Add video_device_release() to release the memory allocated by
video_device_alloc() if something goes wrong. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Balance device refcount when destroying devices
Using device_find_child() to lookup the proper SCMI device to destroy
causes an unbalance in device refcount, since device_find_child() calls an
implicit get_device(): this, in turns, inhibits the call of the provided
release methods upon devices destruction.
As a consequence, one of the structures that is not freed properly upon
destruction is the internal struct device_private dev->p populated by the
drivers subsystem core.
KMemleak detects this situation since loading/unloding some SCMI driver
causes related devices to be created/destroyed without calling any
device_release method.
unreferenced object 0xffff00000f583800 (size 512):
comm "insmod", pid 227, jiffies 4294912190
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6......
backtrace (crc 114e2eed):
kmemleak_alloc+0xbc/0xd8
__kmalloc_cache_noprof+0x2dc/0x398
device_add+0x954/0x12d0
device_register+0x28/0x40
__scmi_device_create.part.0+0x1bc/0x380
scmi_device_create+0x2d0/0x390
scmi_create_protocol_devices+0x74/0xf8
scmi_device_request_notifier+0x1f8/0x2a8
notifier_call_chain+0x110/0x3b0
blocking_notifier_call_chain+0x70/0xb0
scmi_driver_register+0x350/0x7f0
0xffff80000a3b3038
do_one_initcall+0x12c/0x730
do_init_module+0x1dc/0x640
load_module+0x4b20/0x5b70
init_module_from_file+0xec/0x158
$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0
device_add+0x954/0x12d0:
kmalloc_noprof at include/linux/slab.h:901
(inlined by) kzalloc_noprof at include/linux/slab.h:1037
(inlined by) device_private_init at drivers/base/core.c:3510
(inlined by) device_add at drivers/base/core.c:3561
Balance device refcount by issuing a put_device() on devices found via
device_find_child(). |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a memory leak
We forgot to free new_model_number |
| DCMTK v3.6.7 was discovered to contain a memory leak via the T_ASC_Association object. |
| The th_read() function doesn’t free a variable t->th_buf.gnu_longname after allocating memory, which may cause a memory leak. |
| The th_read() function doesn’t free a variable t->th_buf.gnu_longlink after allocating memory, which may cause a memory leak. |
| IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5.0 through 11.5.9 and 12.1.0 through 12.1.1 could allow an authenticated user in federation environment, to cause a denial of service due to insufficient release of allocated memory after usage. |
| FontForge v20230101 was discovered to contain a memory leak via the utf7toutf8_copy function at /fontforge/sfd.c. |
| radare2 v5.9.8 and before contains a memory leak in the function bochs_open. |
| radare2 v5.9.8 and before contains a memory leak in the function r2r_subprocess_init. |
| radare2 v5.9.8 and before contains a memory leak in the function r_bin_object_new. |
| radare2 v.5.9.8 and before contains a memory leak in the function _load_relocations. |
| A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. This issue affects the function H5FL__malloc of the file src/H5FL.c. The manipulation leads to memory leak. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. |
| An issue was discovered in button_open in login/logind-button.c in systemd before 243. When executing the udevadm trigger command, a memory leak may occur. |
| An issue was discovered in Bento4 1.6.0-639. There is a memory leak in the function AP4_File::ParseStream in /Core/Ap4File.cpp. |
| An issue was discovered in Bento4 v1.6.0-639. There is a memory leak in AP4_DescriptorFactory::CreateDescriptorFromStream in Core/Ap4DescriptorFactory.cpp, as demonstrated by mp42aac. |
| In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization. |
