Total
1026 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-38563 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix potential memory leakage when reading chip temperature Without this commit, reading chip temperature will cause memory leakage. | |||||
| CVE-2024-38539 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw When running blktests nvme/rdma, the following kmemleak issue will appear. kmemleak: Kernel memory leak detector initialized (mempool available:36041) kmemleak: Automatic memory scanning thread started kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88855da53400 (size 192): comm "rdma", pid 10630, jiffies 4296575922 hex dump (first 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7............... 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0 [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core] [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core] [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core] [<ffffffffc2a3d389>] 0xffffffffc2a3d389 [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core] [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [<ffffffffc264648c>] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710 [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40 [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420 [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0 [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180 [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause: rdma_put_gid_attr is not called when sgid_attr is set to ERR_PTR(-ENODEV). | |||||
| CVE-2024-36967 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak in tpm2_key_encode() 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case. | |||||
| CVE-2024-35978 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one. | |||||
| CVE-2024-35972 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() If ulp = kzalloc() fails, the allocated edev will leak because it is not properly assigned and the cleanup path will not be able to free it. Fix it by assigning it properly immediately after allocation. | |||||
| CVE-2024-26986 | 2 Fedoraproject, Linux | 2 Fedora, Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leak in create_process failure Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress. | |||||
| CVE-2024-26912 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects. | |||||
| CVE-2024-26900 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: md: fix kmemleak of rdev->serial If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 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 f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 | |||||
| CVE-2024-24267 | 1 Gpac | 1 Gpac | 2024-11-21 | N/A | 7.5 HIGH |
| gpac v2.2.1 was discovered to contain a memory leak via the gfio_blob variable in the gf_fileio_from_blob function. | |||||
| CVE-2024-24258 | 1 Artifex | 1 Mupdf | 2024-11-21 | N/A | 7.5 HIGH |
| freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function. | |||||
| CVE-2024-24149 | 1 Libming | 1 Libming | 2024-11-21 | N/A | 6.5 MEDIUM |
| A memory leak issue discovered in parseSWF_GLYPHENTRY in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. | |||||
| CVE-2024-24147 | 1 Libming | 1 Libming | 2024-11-21 | N/A | 6.5 MEDIUM |
| A memory leak issue discovered in parseSWF_FILLSTYLEARRAY in libming v0.4.8 allows attackers to cause s denial of service via a crafted SWF file. | |||||
| CVE-2024-23820 | 1 Openfga | 1 Openfga | 2024-11-21 | N/A | 5.3 MEDIUM |
| OpenFGA, an authorization/permission engine, is vulnerable to a denial of service attack in versions prior to 1.4.3. In some scenarios that depend on the model and tuples used, a call to `ListObjects` may not release memory properly. So when a sufficiently high number of those calls are executed, the OpenFGA server can create an `out of memory` error and terminate. Version 1.4.3 contains a patch for this issue. | |||||
| CVE-2024-22563 | 1 Openvswitch | 1 Openvswitch | 2024-11-21 | N/A | 7.5 HIGH |
| openvswitch 2.17.8 was discovered to contain a memory leak via the function xmalloc__ in openvswitch-2.17.8/lib/util.c. | |||||
| CVE-2024-21613 | 1 Juniper | 2 Junos, Junos Os Evolved | 2024-11-21 | N/A | 6.5 MEDIUM |
| A Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS). On all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart. The memory usage can be monitored using the below command. user@host> show task memory detail | match patroot This issue affects: Juniper Networks Junos OS * All versions earlier than 21.2R3-S3; * 21.3 versions earlier than 21.3R3-S5; * 21.4 versions earlier than 21.4R3-S3; * 22.1 versions earlier than 22.1R3; * 22.2 versions earlier than 22.2R3. Juniper Networks Junos OS Evolved * All versions earlier than 21.3R3-S5-EVO; * 21.4 versions earlier than 21.4R3-EVO; * 22.1 versions earlier than 22.1R3-EVO; * 22.2 versions earlier than 22.2R3-EVO. | |||||
| CVE-2024-21611 | 1 Juniper | 2 Junos, Junos Os Evolved | 2024-11-21 | N/A | 7.5 HIGH |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network-based attacker to cause a Denial of Service (DoS). In a Juniper Flow Monitoring (jflow) scenario route churn that causes BGP next hops to be updated will cause a slow memory leak and eventually a crash and restart of rpd. Thread level memory utilization for the areas where the leak occurs can be checked using the below command: user@host> show task memory detail | match so_in so_in6 28 32 344450 11022400 344760 11032320 so_in 8 16 1841629 29466064 1841734 29467744 This issue affects: Junos OS * 21.4 versions earlier than 21.4R3; * 22.1 versions earlier than 22.1R3; * 22.2 versions earlier than 22.2R3. Junos OS Evolved * 21.4-EVO versions earlier than 21.4R3-EVO; * 22.1-EVO versions earlier than 22.1R3-EVO; * 22.2-EVO versions earlier than 22.2R3-EVO. This issue does not affect: Juniper Networks Junos OS versions earlier than 21.4R1. Juniper Networks Junos OS Evolved versions earlier than 21.4R1. | |||||
| CVE-2024-21599 | 1 Juniper | 1 Junos | 2024-11-21 | N/A | 6.5 MEDIUM |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on MX Series allows an adjacent, unauthenticated attacker to cause a Denial of Service (DoS). If an MX Series device receives PTP packets on an MPC3E that doesn't support PTP this causes a memory leak which will result in unpredictable behavior and ultimately in an MPC crash and restart. To monitor for this issue, please use the following FPC vty level commands: show heap shows an increase in "LAN buffer" utilization and show clksync ptp nbr-upd-info shows non-zero "Pending PFEs" counter. This issue affects Juniper Networks Junos OS on MX Series with MPC3E: * All versions earlier than 20.4R3-S3; * 21.1 versions earlier than 21.1R3-S4; * 21.2 versions earlier than 21.2R3; * 21.3 versions earlier than 21.3R2-S1, 21.3R3; * 21.4 versions earlier than 21.4R2; * 22.1 versions earlier than 22.1R2. | |||||
| CVE-2023-7192 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2024-11-21 | N/A | 5.5 MEDIUM |
| A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow. | |||||
| CVE-2023-6299 | 1 Itextpdf | 1 Itext | 2024-11-21 | 5.0 MEDIUM | 4.3 MEDIUM |
| A vulnerability, which was classified as problematic, has been found in Apryse iText 8.0.1. This issue affects some unknown processing of the file PdfDocument.java of the component Reference Table Handler. The manipulation leads to memory leak. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 8.0.2 is able to address this issue. It is recommended to upgrade the affected component. The identifier VDB-246125 was assigned to this vulnerability. NOTE: The vendor was contacted early about this vulnerability. The fix was introduced in the iText 8.0.2 release on October 25th 2023, prior to the disclosure. | |||||
| CVE-2023-6180 | 1 Cloudflare | 1 Boring | 2024-11-21 | N/A | 5.3 MEDIUM |
| The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection. | |||||