Total
822 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2020-3753 | 3 Adobe, Apple, Microsoft | 4 Acrobat Dc, Acrobat Reader Dc, Macos and 1 more | 2024-08-04 | 7.5 High |
| Adobe Acrobat and Reader versions 2019.021.20061 and earlier, 2017.011.30156 and earlier, 2017.011.30156 and earlier, and 2015.006.30508 and earlier have a stack exhaustion vulnerability. Successful exploitation could lead to memory leak . | ||||
| CVE-2020-3756 | 3 Adobe, Apple, Microsoft | 4 Acrobat Dc, Acrobat Reader Dc, Macos and 1 more | 2024-08-04 | 7.5 High |
| Adobe Acrobat and Reader versions 2019.021.20061 and earlier, 2017.011.30156 and earlier, 2017.011.30156 and earlier, and 2015.006.30508 and earlier have a stack exhaustion vulnerability. Successful exploitation could lead to memory leak . | ||||
| CVE-2020-1883 | 1 Huawei | 6 Nip6800, Nip6800 Firmware, Secospace Usg6600 and 3 more | 2024-08-04 | 4.9 Medium |
| Huawei products NIP6800;Secospace USG6600;USG9500 have a memory leak vulnerability. An attacker with high privileges exploits this vulnerability by continuously performing specific operations. Successful exploitation of this vulnerability can cause service abnormal. | ||||
| CVE-2020-1815 | 1 Huawei | 6 Nip6800, Nip6800 Firmware, Secospace Usg6600 and 3 more | 2024-08-04 | 7.5 High |
| Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00; Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00 have a memory leak vulnerability. The software does not sufficiently track and release allocated memory while parse certain message, the attacker sends the message continuously that could consume remaining memory. Successful exploit could cause memory exhaust. | ||||
| CVE-2020-0491 | 1 Google | 1 Android | 2024-08-04 | 6.5 Medium |
| In readBlock of MatroskaExtractor.cpp, there is a possible denial of service due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-156819528 | ||||
| CVE-2021-47550 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put. | ||||
| CVE-2021-47568 | 2024-08-04 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memleak in get_file_stream_info() Fix memleak in get_file_stream_info() | ||||
| CVE-2021-47570 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: staging: r8188eu: fix a memory leak in rtw_wx_read32() Free "ptmp" before returning -EINVAL. | ||||
| CVE-2021-47529 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iwlwifi: Fix memory leaks in error handling path Should an error occur (invalid TLV len or memory allocation failure), the memory already allocated in 'reduce_power_data' should be freed before returning, otherwise it is leaking. | ||||
| CVE-2021-47513 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering Avoid a memory leak if there is not a CPU port defined. Addresses-Coverity-ID: 1492897 ("Resource leak") Addresses-Coverity-ID: 1492899 ("Resource leak") | ||||
| CVE-2021-47534 | 2024-08-04 | 3.4 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Add missing drm_crtc_commit_put Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. | ||||
| CVE-2021-47546 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: fix memory leak in fib6_rule_suppress The kernel leaks memory when a `fib` rule is present in IPv6 nftables firewall rules and a suppress_prefix rule is present in the IPv6 routing rules (used by certain tools such as wg-quick). In such scenarios, every incoming packet will leak an allocation in `ip6_dst_cache` slab cache. After some hours of `bpftrace`-ing and source code reading, I tracked down the issue to ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule"). The problem with that change is that the generic `args->flags` always have `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not decreasing the refcount when needed. How to reproduce: - Add the following nftables rule to a prerouting chain: meta nfproto ipv6 fib saddr . mark . iif oif missing drop This can be done with: sudo nft create table inet test sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }' sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop - Run: sudo ip -6 rule add table main suppress_prefixlength 0 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase with every incoming ipv6 packet. This patch exposes the protocol-specific flags to the protocol specific `suppress` function, and check the protocol-specific `flags` argument for RT6_LOOKUP_F_DST_NOREF instead of the generic FIB_LOOKUP_NOREF when decreasing the refcount, like this. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99 | ||||
| CVE-2021-47519 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_read_fifo: fix memory leak in error branch In m_can_read_fifo(), if the second call to m_can_fifo_read() fails, the function jump to the out_fail label and returns without calling m_can_receive_skb(). This means that the skb previously allocated by alloc_can_skb() is not freed. In other terms, this is a memory leak. This patch adds a goto label to destroy the skb if an error occurs. Issue was found with GCC -fanalyzer, please follow the link below for details. | ||||
| CVE-2021-47537 | 1 Linux | 1 Linux Kernel | 2024-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix a memleak bug in rvu_mbox_init() In rvu_mbox_init(), mbox_regions is not freed or passed out under the switch-default region, which could lead to a memory leak. Fix this bug by changing 'return err' to 'goto free_regions'. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_OCTEONTX2_AF=y show no new warnings, and our static analyzer no longer warns about this code. | ||||
| CVE-2021-47538 | 2024-08-04 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer() Need to call rxrpc_put_local() for peer candidate before kfree() as it holds a ref to rxrpc_local. [DH: v2: Changed to abstract the peer freeing code out into a function] | ||||
| CVE-2021-47539 | 2024-08-04 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle() Need to call rxrpc_put_peer() for bundle candidate before kfree() as it holds a ref to rxrpc_peer. [DH: v2: Changed to abstract out the bundle freeing code into a function] | ||||
| CVE-2021-47420 | 2024-08-04 | 2.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix a potential ttm->sg memory leak Memory is allocated for ttm->sg by kmalloc in kfd_mem_dmamap_userptr, but isn't freed by kfree in kfd_mem_dmaunmap_userptr. Free it! | ||||
| CVE-2021-47431 | 2024-08-04 | 2.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gart.bo pin_count leak gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. | ||||
| CVE-2021-47416 | 2024-08-04 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. | ||||
| CVE-2021-47403 | 2024-08-04 | 7.1 High | ||
| In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix module reference leak A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped. Fix this by taking the module reference and initialising the tty driver data when installing the tty. | ||||