Total
1159 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2012-3954 | 4 Canonical, Debian, Isc and 1 more | 4 Ubuntu Linux, Debian Linux, Dhcp and 1 more | 2025-04-11 | N/A |
Multiple memory leaks in ISC DHCP 4.1.x and 4.2.x before 4.2.4-P1 and 4.1-ESV before 4.1-ESV-R6 allow remote attackers to cause a denial of service (memory consumption) by sending many requests. | ||||
CVE-2012-3868 | 1 Isc | 1 Bind | 2025-04-11 | N/A |
Race condition in the ns_client structure management in ISC BIND 9.9.x before 9.9.1-P2 allows remote attackers to cause a denial of service (memory consumption or process exit) via a large volume of TCP queries. | ||||
CVE-2012-3420 | 1 Sgi | 1 Performance Co-pilot | 2025-04-11 | N/A |
Multiple memory leaks in Performance Co-Pilot (PCP) before 3.6.5 allow remote attackers to cause a denial of service (memory consumption or daemon crash) via a large number of PDUs with (1) a crafted context number to the DoFetch function in pmcd/src/dofetch.c or (2) a negative type value to the __pmGetPDU function in libpcp/src/pdu.c. | ||||
CVE-2012-2390 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Enterprise Mrg | 2025-04-11 | N/A |
Memory leak in mm/hugetlb.c in the Linux kernel before 3.4.2 allows local users to cause a denial of service (memory consumption or system crash) via invalid MAP_HUGETLB mmap operations. | ||||
CVE-2011-1576 | 2 Linux, Redhat | 5 Linux Kernel, Enterprise Linux, Enterprise Mrg and 2 more | 2025-04-11 | N/A |
The Generic Receive Offload (GRO) implementation in the Linux kernel 2.6.18 on Red Hat Enterprise Linux 5 and 2.6.32 on Red Hat Enterprise Linux 6, as used in Red Hat Enterprise Virtualization (RHEV) Hypervisor and other products, allows remote attackers to cause a denial of service via crafted VLAN packets that are processed by the napi_reuse_skb function, leading to (1) a memory leak or (2) memory corruption, a different vulnerability than CVE-2011-1478. | ||||
CVE-2012-1148 | 3 Apple, Libexpat Project, Redhat | 4 Mac Os X, Libexpat, Enterprise Linux and 1 more | 2025-04-11 | N/A |
Memory leak in the poolGrow function in expat/lib/xmlparse.c in expat before 2.1.0 allows context-dependent attackers to cause a denial of service (memory consumption) via a large number of crafted XML files that cause improperly-handled reallocation failures when expanding entities. | ||||
CVE-2024-21609 | 1 Juniper | 38 Csrx, Junos, Mx240 and 35 more | 2025-04-10 | 6.5 Medium |
A Missing Release of Memory after Effective Lifetime vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX Series with SPC3, and SRX Series allows an administratively adjacent attacker which is able to successfully establish IPsec tunnels to cause a Denial of Service (DoS). If specific values for the IPsec parameters local-ip, remote-ip, remote ike-id, and traffic selectors are sent from the peer, a memory leak occurs during every IPsec SA rekey which is carried out with a specific message sequence. This will eventually result in an iked process crash and restart. The iked process memory consumption can be checked using the below command: user@host> show system processes extensive | grep iked PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56903 root 31 0 4016M 2543M CPU0 0 2:10 10.50% iked This issue affects Juniper Networks Junos OS: * All versions earlier than 20.4R3-S9; * 21.2 versions earlier than 21.2R3-S7; * 21.3 versions earlier than 21.3R3-S5; * 21.4 versions earlier than 21.4R3-S4; * 22.1 versions earlier than 22.1R3-S3; * 22.2 versions earlier than 22.2R3-S2; * 22.3 versions earlier than 22.3R3; * 22.4 versions earlier than 22.4R3; * 23.2 versions earlier than 23.2R1-S2, 23.2R2. | ||||
CVE-2025-22000 | 1 Linux | 1 Linux Kernel | 2025-04-10 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: drop beyond-EOF folios with the right number of refs When an after-split folio is large and needs to be dropped due to EOF, folio_put_refs(folio, folio_nr_pages(folio)) should be used to drop all page cache refs. Otherwise, the folio will not be freed, causing memory leak. This leak would happen on a filesystem with blocksize > page_size and a truncate is performed, where the blocksize makes folios split to >0 order ones, causing truncated folios not being freed. | ||||
CVE-2025-22005 | 1 Linux | 1 Linux Kernel | 2025-04-10 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git. | ||||
CVE-2022-46490 | 1 Gpac | 1 Gpac | 2025-04-10 | 5.5 Medium |
GPAC version 2.1-DEV-rev505-gb9577e6ad-master was discovered to contain a memory leak via the afrt_box_read function at box_code_adobe.c. | ||||
CVE-2022-46489 | 1 Gpac | 1 Gpac | 2025-04-10 | 5.5 Medium |
GPAC version 2.1-DEV-rev505-gb9577e6ad-master was discovered to contain a memory leak via the gf_isom_box_parse_ex function at box_funcs.c. | ||||
CVE-2025-21981 | 1 Linux | 1 Linux Kernel | 2025-04-10 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: ice: fix memory leak in aRFS after reset Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 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 (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... | ||||
CVE-2022-49636 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-04-10 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: vlan: fix memory leak in vlan_newlink() Blamed commit added back a bug I fixed in commit 9bbd917e0bec ("vlan: fix memory leak in vlan_dev_set_egress_priority") If a memory allocation fails in vlan_changelink() after other allocations succeeded, we need to call vlan_dev_free_egress_priority() to free all allocated memory because after a failed ->newlink() we do not call any methods like ndo_uninit() or dev->priv_destructor(). In following example, if the allocation for last element 2000:2001 fails, we need to free eight prior allocations: ip link add link dummy0 dummy0.100 type vlan id 100 \ egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001 syzbot report was: BUG: memory leak unreferenced object 0xffff888117bd1060 (size 32): comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s) hex dump (first 32 bytes): 09 00 00 00 00 a0 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: [<ffffffff83fc60ad>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83fc60ad>] vlan_dev_set_egress_priority+0xed/0x170 net/8021q/vlan_dev.c:193 [<ffffffff83fc6628>] vlan_changelink+0x178/0x1d0 net/8021q/vlan_netlink.c:128 [<ffffffff83fc67c8>] vlan_newlink+0x148/0x260 net/8021q/vlan_netlink.c:185 [<ffffffff838b1278>] rtnl_newlink_create net/core/rtnetlink.c:3363 [inline] [<ffffffff838b1278>] __rtnl_newlink+0xa58/0xdc0 net/core/rtnetlink.c:3580 [<ffffffff838b1629>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3593 [<ffffffff838ac66c>] rtnetlink_rcv_msg+0x21c/0x5c0 net/core/rtnetlink.c:6089 [<ffffffff839f9c37>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2501 [<ffffffff839f8da7>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff839f8da7>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839f9266>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff8384dbf6>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8384dbf6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8384e15c>] ____sys_sendmsg+0x36c/0x390 net/socket.c:2488 [<ffffffff838523cb>] ___sys_sendmsg+0x8b/0xd0 net/socket.c:2542 [<ffffffff838525b8>] __sys_sendmsg net/socket.c:2571 [inline] [<ffffffff838525b8>] __do_sys_sendmsg net/socket.c:2580 [inline] [<ffffffff838525b8>] __se_sys_sendmsg net/socket.c:2578 [inline] [<ffffffff838525b8>] __x64_sys_sendmsg+0x78/0xf0 net/socket.c:2578 [<ffffffff845ad8d5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845ad8d5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff8460006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ||||
CVE-2022-49546 | 1 Linux | 1 Linux Kernel | 2025-04-10 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. | ||||
CVE-2024-53215 | 1 Linux | 1 Linux Kernel | 2025-04-09 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init() There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: <TASK> __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the 'percpu_counters' list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL. | ||||
CVE-2008-6218 | 1 Libpng | 1 Libpng | 2025-04-09 | N/A |
Memory leak in the png_handle_tEXt function in pngrutil.c in libpng before 1.2.33 rc02 and 1.4.0 beta36 allows context-dependent attackers to cause a denial of service (memory exhaustion) via a crafted PNG file. | ||||
CVE-2008-3652 | 2 Ipsec-tools, Redhat | 2 Ipsec-tools, Enterprise Linux | 2025-04-09 | N/A |
src/racoon/handler.c in racoon in ipsec-tools does not remove an "orphaned ph1" (phase 1) handle when it has been initiated remotely, which allows remote attackers to cause a denial of service (resource consumption). | ||||
CVE-2008-4298 | 1 Lighttpd | 1 Lighttpd | 2025-04-09 | N/A |
Memory leak in the http_request_parse function in request.c in lighttpd before 1.4.20 allows remote attackers to cause a denial of service (memory consumption) via a large number of requests with duplicate request headers. | ||||
CVE-2008-3913 | 2 Clamav, Debian | 2 Clamav, Debian Linux | 2025-04-09 | N/A |
Multiple memory leaks in freshclam/manager.c in ClamAV before 0.94 might allow attackers to cause a denial of service (memory consumption) via unspecified vectors related to "error handling logic". | ||||
CVE-2009-1632 | 2 Ipsec-tools, Redhat | 2 Ipsec-tools, Enterprise Linux | 2025-04-09 | N/A |
Multiple memory leaks in Ipsec-tools before 0.7.2 allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) signature verification during user authentication with X.509 certificates, related to the eay_check_x509sign function in src/racoon/crypto_openssl.c; and (2) the NAT-Traversal (aka NAT-T) keepalive implementation, related to src/racoon/nattraversal.c. |