Total
1025 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2022-45204 | 1 Gpac | 1 Gpac | 2025-04-25 | N/A | 5.5 MEDIUM |
GPAC v2.1-DEV-rev428-gcb8ae46c8-master was discovered to contain a memory leak via the function dimC_box_read at isomedia/box_code_3gpp.c. | |||||
CVE-2021-47671 | 1 Linux | 1 Linux Kernel | 2025-04-21 | N/A | 3.3 LOW |
In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path In es58x_rx_err_msg(), if can->do_set_mode() fails, the function directly returns without calling netif_rx(skb). This means that the skb previously allocated by alloc_can_err_skb() is not freed. In other terms, this is a memory leak. This patch simply removes the return statement in the error branch and let the function continue. Issue was found with GCC -fanalyzer, please follow the link below for details. | |||||
CVE-2016-10155 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 4.9 MEDIUM | 6.0 MEDIUM |
Memory leak in hw/watchdog/wdt_i6300esb.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations. | |||||
CVE-2015-8567 | 6 Canonical, Debian, Fedoraproject and 3 more | 10 Ubuntu Linux, Debian Linux, Fedora and 7 more | 2025-04-20 | 6.8 MEDIUM | 7.7 HIGH |
Memory leak in net/vmxnet3.c in QEMU allows remote attackers to cause a denial of service (memory consumption). | |||||
CVE-2017-5579 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in the serial_exit_core function in hw/char/serial.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations. | |||||
CVE-2017-5856 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in the megasas_handle_dcmd function in hw/scsi/megasas.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption) via MegaRAID Firmware Interface (MFI) commands with the sglist size set to a value over 2 Gb. | |||||
CVE-2017-9373 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 1.9 LOW | 5.5 MEDIUM |
Memory leak in QEMU (aka Quick Emulator), when built with IDE AHCI Emulation support, allows local guest OS privileged users to cause a denial of service (memory consumption) by repeatedly hot-unplugging the AHCI device. | |||||
CVE-2017-5525 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in hw/audio/ac97.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations. | |||||
CVE-2017-9060 | 1 Qemu | 1 Qemu | 2025-04-20 | 4.9 MEDIUM | 5.5 MEDIUM |
Memory leak in the virtio_gpu_set_scanout function in hw/display/virtio-gpu.c in QEMU (aka Quick Emulator) allows local guest OS users to cause a denial of service (memory consumption) via a large number of "VIRTIO_GPU_CMD_SET_SCANOUT:" commands. | |||||
CVE-2017-5526 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in hw/audio/es1370.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations. | |||||
CVE-2017-9374 | 1 Qemu | 1 Qemu | 2025-04-20 | 2.1 LOW | 5.5 MEDIUM |
Memory leak in QEMU (aka Quick Emulator), when built with USB EHCI Emulation support, allows local guest OS privileged users to cause a denial of service (memory consumption) by repeatedly hot-unplugging the device. | |||||
CVE-2017-5857 | 1 Qemu | 1 Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in the virgl_cmd_resource_unref function in hw/display/virtio-gpu-3d.c in QEMU (aka Quick Emulator) allows local guest OS users to cause a denial of service (host memory consumption) via a large number of VIRTIO_GPU_CMD_RESOURCE_UNREF commands sent without detaching the backing storage beforehand. | |||||
CVE-2017-5578 | 1 Qemu | 1 Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in the virtio_gpu_resource_attach_backing function in hw/display/virtio-gpu.c in QEMU (aka Quick Emulator) allows local guest OS users to cause a denial of service (host memory consumption) via a large number of VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING commands. | |||||
CVE-2017-5552 | 1 Qemu | 1 Qemu | 2025-04-20 | 4.9 MEDIUM | 6.5 MEDIUM |
Memory leak in the virgl_resource_attach_backing function in hw/display/virtio-gpu-3d.c in QEMU (aka Quick Emulator) allows local guest OS users to cause a denial of service (host memory consumption) via a large number of VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING commands. | |||||
CVE-2024-56748 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). | |||||
CVE-2024-56746 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. | |||||
CVE-2024-56745 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reset_method_store() memory leak In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces: while ((name = strsep(&options, " ")) != NULL) { If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup(). Fix by using a separate tmp_options to iterate with strsep() so options is preserved. | |||||
CVE-2024-56742 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() Fix an unwind issue in mlx5vf_add_migration_pages(). If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak. Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer(). | |||||
CVE-2024-56712 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix memory leak on last export_udmabuf() error path In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a dma_buf owning the udmabuf has already been created; but the error handling in udmabuf_create() will tear down the udmabuf without doing anything about the containing dma_buf. This leaves a dma_buf in memory that contains a dangling pointer; though that doesn't seem to lead to anything bad except a memory leak. Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we can give it different error handling. Note that the shape of this code changed a lot in commit 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios"); but the memory leak seems to have existed since the introduction of udmabuf. | |||||
CVE-2024-56710 | 1 Linux | 1 Linux Kernel | 2025-04-17 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_direct_read_write() The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked and pages remain pinned if ceph_alloc_sparse_ext_map() fails. There is no need to delay the allocation of sparse_ext map until after the bvecs array is set up, so fix this by moving sparse_ext allocation a bit earlier. Also, make a similar adjustment in __ceph_sync_read() for consistency (a leak of the same kind in __ceph_sync_read() has been addressed differently). |