Total
644 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2010-2942 | 6 Avaya, Canonical, Linux and 3 more | 13 Aura Communication Manager, Aura Presence Services, Aura Session Manager and 10 more | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| The actions implementation in the network queueing functionality in the Linux kernel before 2.6.36-rc2 does not properly initialize certain structure members when performing dump operations, which allows local users to obtain potentially sensitive information from kernel memory via vectors related to (1) the tcf_gact_dump function in net/sched/act_gact.c, (2) the tcf_mirred_dump function in net/sched/act_mirred.c, (3) the tcf_nat_dump function in net/sched/act_nat.c, (4) the tcf_simp_dump function in net/sched/act_simple.c, and (5) the tcf_skbedit_dump function in net/sched/act_skbedit.c. | |||||
| CVE-2010-2249 | 8 Apple, Canonical, Debian and 5 more | 12 Iphone Os, Itunes, Safari and 9 more | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
| Memory leak in pngrutil.c in libpng before 1.2.44, and 1.4.x before 1.4.3, allows remote attackers to cause a denial of service (memory consumption and application crash) via a PNG image containing malformed Physical Scale (aka sCAL) chunks. | |||||
| CVE-2009-5063 | 1 Libpng | 1 Libpng | 2024-11-21 | 5.0 MEDIUM | N/A |
| Memory leak in the embedded_profile_len function in pngwutil.c in libpng before 1.2.39beta5 allows context-dependent attackers to cause a denial of service (memory leak or segmentation fault) via a JPEG image containing an iCCP chunk with a negative embedded profile length. NOTE: this is due to an incomplete fix for CVE-2006-7244. | |||||
| CVE-2009-1378 | 2 Canonical, Openssl | 2 Ubuntu Linux, Openssl | 2024-11-21 | 5.0 MEDIUM | N/A |
| Multiple memory leaks in the dtls1_process_out_of_seq_message function in ssl/d1_both.c in OpenSSL 0.9.8k and earlier 0.9.8 versions allow remote attackers to cause a denial of service (memory consumption) via DTLS records that (1) are duplicates or (2) have sequence numbers much greater than current sequence numbers, aka "DTLS fragment handling memory leak." | |||||
| CVE-2009-0581 | 4 Gimp, Littlecms, Mozilla and 1 more | 4 Gimp, Little Cms, Firefox and 1 more | 2024-11-21 | 4.3 MEDIUM | N/A |
| Memory leak in LittleCMS (aka lcms or liblcms) before 1.18beta2, as used in Firefox 3.1beta, OpenJDK, and GIMP, allows context-dependent attackers to cause a denial of service (memory consumption and application crash) via a crafted image file. | |||||
| CVE-2008-3913 | 2 Clamav, Debian | 2 Clamav, Debian Linux | 2024-11-21 | 5.0 MEDIUM | 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-2007-2274 | 1 Opera | 1 Opera Browser | 2024-11-21 | 7.8 HIGH | N/A |
| The BitTorrent implementation in Opera 9.2 allows remote attackers to cause a denial of service (CPU consumption and application crash) via a malformed torrent file. NOTE: the original disclosure refers to this as a memory leak, but it is not certain. | |||||
| CVE-2005-3181 | 4 Canonical, Debian, Linux and 1 more | 4 Ubuntu Linux, Debian Linux, Linux Kernel and 1 more | 2024-11-21 | 2.1 LOW | N/A |
| The audit system in Linux kernel 2.6.6, and other versions before 2.6.13.4, when CONFIG_AUDITSYSCALL is enabled, uses an incorrect function to free names_cache memory, which prevents the memory from being tracked by AUDITSYSCALL code and leads to a memory leak that allows attackers to cause a denial of service (memory consumption). | |||||
| CVE-2004-0427 | 1 Linux | 1 Linux Kernel | 2024-11-20 | 2.1 LOW | N/A |
| The do_fork function in Linux 2.4.x before 2.4.26, and 2.6.x before 2.6.6, does not properly decrement the mm_count counter when an error occurs after the mm_struct for a child process has been activated, which triggers a memory leak that allows local users to cause a denial of service (memory exhaustion) via the clone (CLONE_VM) system call. | |||||
| CVE-2004-0222 | 1 Openbsd | 1 Openbsd | 2024-11-20 | 5.0 MEDIUM | N/A |
| Multiple memory leaks in isakmpd in OpenBSD 3.4 and earlier allow remote attackers to cause a denial of service (memory exhaustion) via certain ISAKMP packets, as demonstrated by the Striker ISAKMP Protocol Test Suite. | |||||
| CVE-2002-0574 | 1 Freebsd | 1 Freebsd | 2024-11-20 | 5.0 MEDIUM | N/A |
| Memory leak in FreeBSD 4.5 and earlier allows remote attackers to cause a denial of service (memory exhaustion) via ICMP echo packets that trigger a bug in ip_output() in which the reference count for a routing table entry is not decremented, which prevents the entry from being removed. | |||||
| CVE-2001-0543 | 1 Microsoft | 3 Exchange Server, Windows 2000, Windows Nt | 2024-11-20 | 5.0 MEDIUM | N/A |
| Memory leak in NNTP service in Windows NT 4.0 and Windows 2000 allows remote attackers to cause a denial of service (memory exhaustion) via a large number of malformed posts. | |||||
| CVE-2001-0136 | 4 Conectiva, Debian, Mandrakesoft and 1 more | 4 Linux, Debian Linux, Mandrake Linux and 1 more | 2024-11-20 | 5.0 MEDIUM | N/A |
| Memory leak in ProFTPd 1.2.0rc2 allows remote attackers to cause a denial of service via a series of USER commands, and possibly SIZE commands if the server has been improperly installed. | |||||
| CVE-2024-3860 | 2024-11-20 | N/A | 6.2 MEDIUM | ||
| An out-of-memory condition during object initialization could result in an empty shape list. If the JIT subsequently traced the object it would crash. This vulnerability affects Firefox < 125. | |||||
| CVE-2024-8376 | 1 Eclipse | 1 Mosquitto | 2024-11-15 | N/A | 7.5 HIGH |
| In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets. | |||||
| CVE-2024-50254 | 1 Linux | 1 Linux Kernel | 2024-11-14 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm "swapper/0", pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to check whether the iteration is complete and still use "nr_bits > 64" to indicate whether bits are dynamically allocated. The "!nr_bits" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch. | |||||
| CVE-2024-50252 | 1 Linux | 1 Linux Kernel | 2024-11-14 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: <TASK> mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm "ip", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0 | |||||
| CVE-2024-50236 | 1 Linux | 1 Linux Kernel | 2024-11-14 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110 [<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400 [<ffffffe6e78d60b8>] worker_thread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 | |||||
| CVE-2021-47031 | 2024-11-13 | N/A | 4.3 MEDIUM | ||
| In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix memory leak in mt7921_coredump_work Fix possible memory leak in mt7921_coredump_work. | |||||
| CVE-2024-50171 | 1 Linux | 1 Linux Kernel | 2024-11-13 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it. | |||||