CWE-772 CVEs · Low

Look up CVE IDs Status Exploitation Severity

Reset

Overview 18 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

18matches 0in Waratek scope0.0% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0% Outside Waratek scope 0 0.0% Not applicable 18 100.0% Withdrawn CVE 0 0.0%

Critical 0 0.0% High 0 0.0% Medium 0 0.0% Low 18 100.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 18 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 5.6% Forecast only 0 0.0% No public exploit 17 94.4%

split by StatusSeverityProtectionExploit maturity peak 6 / year

20185 Not applicable5 Low5 not blocked5 No public exploit5 20191 Not applicable1 Low1 not blocked1 No public exploit1 20201 Not applicable1 Low1 not blocked1 No public exploit1 20210 20221 Not applicable1 Low1 not blocked1 No public exploit1 20230 20240 20254 Not applicable4 Low4 not blocked4 No public exploit4 20266 Not applicable6 Low6 not blocked6 Proof of concept only1 No public exploit5

201820192020202120222023202420252026

18 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-114236	Low	2026-10-21	Not applicable	No public exploit	storage/pkg/archive.ApplyLayer and ApplyUncompressedLayer may, when processing corrupt or malicious inputs, leak a file descriptor; unbounded repeated calls can exhaust the process’ file descriptor limit
CVE-2026-77205	Low	2026-10-13	Not applicable	No public exploit	Libreswan in FIPS mode has a vulnerability where badly formed received certificates are rejected, but not deleted from the NSS cache. As a result, any real certificates with the same serial number are rejected as well. This can be abused to lock out legitimate peers from connecting. The add_decoded_cert() function missed a call to CERT_DestroyCertificate() due to an incorrect fix for CVE-2026-14957. Sending bogus certificates with new serial numbers could prevent the real certificates with those serial numbers from connecting until the service has restarted.
CVE-2026-11811	Low	2026-08-10	Not applicable	No public exploit	The UpdateHub over-the-air update client's start_coap_client() in subsys/mgmt/updatehub/updatehub.c leaks the CoAP/DTLS socket descriptor on its connection-setup failure paths. The shared error: cleanup gated socket closing on a ret > 0 flag, but ret was set to -1 immediately after the socket was created, so when zsock_setsockopt() (DTLS) or zsock_connect() subsequently failed the gate was false and cleanup_connection() was never called. The open descriptor in the global ctx.sock was then overwritten by the next attempt, permanently leaking it from the socket / net_context pool until reboot. The failing setup path is reached every time the OTA client tries to contact the UpdateHub server and the connection cannot be established — driven automatically by the periodic autohandler() poll (and on demand via the updatehub_probe()/updatehub_update() API or the updatehub run shell command). The DTLS handshake/connect outcome is influenceable by a network or on-path attacker who drops, resets, or otherwise disrupts traffic to the server, and also fails naturally whenever the server is unreachable. Each failed attempt permanently leaks one descriptor; once the shared socket pool is exhausted, networking degrades device-wide until the device is rebooted, a denial-of-service condition. Severity is low because the leak rate is bounded by the configured OTA poll interval (default once per 24 hours), the effect is gradual and recovered by reboot, and only builds with the UpdateHub client enabled are affected. There is no memory-corruption, information-disclosure, or authentication impact.
CVE-2026-41637	Low	2026-07-22	Not applicable	No public exploit	In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, client terminated DNS-over-QUIC (DoQ) queries are not accounted properly by Unbound resulting in low-cost inflation of the waiting number of replies for already in-flight resolution queries. This results in degradation of resolution service for new clients for already in-flight queries. A malicious actor can exploit the vulnerability by issuing DoQ queries for query names that need resolution and proceeding on immediately terminating the query by one of STOP_SENDING/RESET_STREAM/CONNECTION_CLOSE QUIC frames. Those terminated DoQ queries are not properly counted for and keep inflating the number of waiting replies for in-flight queries. When the maximum is reached, it results in silent query drops for new clients needing resolution for already in-flight queries. This vulnerability needs Unbound to be compiled with DoQ support ('--with-libngtcp2') and the 'quic-port' to be configured for the listening interfaces. Additionally, a malicious actor needs access to multiple source IPs to bypass the by-default configured 'wait-limit' option.
CVE-2026-54786	Low	2026-07-01	Not applicable	No public exploit	Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2.
CVE-2026-45287	Low	2026-06-04	Not applicable	Proof of concept only	OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.0.17, `go.opentelemetry.io/otel/schema/v1.0` and `go.opentelemetry.io/otel/schema/v1.1` leaks one file descriptor on each successful `ParseFile` call. `ParseFile` opens the schema file and passes it to `Parse` without closing it; repeated parsing in a long-running process can exhaust the process file descriptor limit and cause denial of service. Exploitation depends on a consuming application exposing repeated schema parsing to an attacker-controlled path. Version 0.0.17 contains a patch for the issue.
CVE-2025-64734	Low	2025-11-18	Not applicable	No public exploit	Missing Release of Resource after Effective Lifetime (CWE-772) in the T21 Reader allows an attacker with physical access to the Reader to perform a denial-of-service attack against that specific reader, preventing cardholders from badging for entry. This issue affects Command Centre Server: 9.30 prior to vCR9.30.251028a (distributed in 9.30.2881 (MR3)), 9.20 prior to vCR9.20.251028a (distributed in 9.20.3265 (MR5)), 9.10 prior to vCR9.10.251028a (distributed in 9.10.4135 (MR8)), all versions of 9.00 and prior.
CVE-2025-61670	Low	2025-10-07	Not applicable	No public exploit	Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak. Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted<T>` type to a new `OwnedRooted<T>` type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted<T>`, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks. In migrating to `OwnedRooted<T>` the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the `OwnedRooted<T>` type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of `OwnedRooted<T>` vs `ManuallyRooted<T>` is that the `OwnedRooted<T>` type allocates host memory outside of the store. This means that if an `OwnedRooted<T>` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host. This led to a few distinct, but related, issues arising: A typo in the `wasmtime_val_unroot` function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a `wasmtime_{externref,anyref}_t` value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when `OwnedRooted<T>` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values. These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example `wasmtime_val_unroot` has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the `ExternRef`, `AnyRef`, and `Val` types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and `main` in the Wasmtime repository) include minor API updates to better accommodate the API semantic changes. The only known workaround at this time is to avoid using `externref` and `anyref` in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue.
CVE-2025-0036	Low	2025-06-10	Not applicable	No public exploit	In AMD Versal Adaptive SoC devices, the incorrect configuration of the SSS during runtime (post-boot) cryptographic operations could cause data to be incorrectly written to and read from invalid locations as well as returning incorrect cryptographic data.
CVE-2025-3864	Low	2025-05-28	Not applicable	No public exploit	Hackney fails to properly release HTTP connections to the pool after handling 307 Temporary Redirect responses. Remote attackers can exploit this to exhaust connection pools, causing denial of service in applications using the library. Fix for this issue has been included in 1.24.0 release.
CVE-2022-26354	Low	2022-03-16	Not applicable	No public exploit	A flaw was found in the vhost-vsock device of QEMU. In case of error, an invalid element was not detached from the virtqueue before freeing its memory, leading to memory leakage and other unexpected results. Affected QEMU versions <= 6.2.0.
CVE-2020-27351	Low	2020-12-10	Not applicable	No public exploit	Various memory and file descriptor leaks were found in apt-python files python/arfile.cc, python/tag.cc, python/tarfile.cc, aka GHSL-2020-170. This issue affects: python-apt 1.1.0~beta1 versions prior to 1.1.0~beta1ubuntu0.16.04.10; 1.6.5ubuntu0 versions prior to 1.6.5ubuntu0.4; 2.0.0ubuntu0 versions prior to 2.0.0ubuntu0.20.04.2; 2.1.3ubuntu1 versions prior to 2.1.3ubuntu1.1;
CVE-2019-19533	Low	2019-12-03	Not applicable	No public exploit	In the Linux kernel before 5.3.4, there is an info-leak bug that can be caused by a malicious USB device in the drivers/media/usb/ttusb-dec/ttusb_dec.c driver, aka CID-a10feaf8c464.
CVE-2017-17330	Low	2018-03-09	Not applicable	No public exploit	Huawei AR3200 V200R005C32; V200R006C10; V200R006C11; V200R007C00; V200R007C01; V200R007C02; V200R008C00; V200R008C10; V200R008C20; V200R008C30; NGFW Module V500R001C00; V500R001C20; V500R002C00 have a memory leak vulnerability. The software does not release allocated memory properly when parse XML element data. An authenticated attacker could upload a crafted XML file, successful exploit could cause the system service abnormal since run out of memory.
CVE-2017-17329	Low	2018-03-09	Not applicable	No public exploit	Huawei ViewPoint 8660 V100R008C03 have a memory leak vulnerability. The software does not release allocated memory properly when parse XML Schema data. An authenticated attacker could upload a crafted XML file, successful exploit could cause the system service abnormal since run out of memory.
CVE-2017-17141	Low	2018-03-05	Not applicable	No public exploit	Huawei S12700 V200R005C00; V200R006C00; V200R007C00; V200R007C01; V200R007C20; V200R008C00; V200R009C00;S1700 V200R006C10; V200R009C00;S2700 V100R006C03; V200R003C00; V200R005C00; V200R006C00; V200R006C10; V200R007C00; V200R007C00B050; V200R007C00SPC009T; V200R007C00SPC019T; V200R008C00; V200R009C00;S3700 V100R006C03;S5700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R003C02; V200R005C00; V200R005C01; V200R005C02; V200R005C03; V200R006C00; V200R007C00; V200R008C00; V200R009C00;S6700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R005C01; V200R005C02; V200R008C00; V200R009C00;S7700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R006C00; V200R006C01; V200R007C00; V200R007C01; V200R008C00; V200R008C06; V200R009C00;S9700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R006C00; V200R007C00; V200R007C01; V200R008C00; V200R009C00 have a memory leak vulnerability. In some specific conditions, if attackers send specific malformed MPLS Service PING messages to the affected products, products do not release the memory when handling the packets. So successful exploit will result in memory leak of the affected products.
CVE-2017-17302	Low	2018-02-15	Not applicable	No public exploit	Huawei DP300 V500R002C00, RP200 V600R006C00, TE30 V100R001C10, V500R002C00, V600R006C00, TE40 V500R002C00, V600R006C00, TE50 V500R002C00, V600R006C00, TE60 V100R001C10, V500R002C00, V600R006C00 have a memory leak vulnerability. An authenticated, local attacker may craft and load some specific Certificate Revocation List(CRL) configuration files to the devices repeatedly. Due to not release allocated memory properly, successful exploit may result in memory leak and services abnormal.
CVE-2017-17289	Low	2018-02-15	Not applicable	No public exploit	Huawei DP300 V500R002C00, RP200 V500R002C00, V600R006C00, TE30 V100R001C10, V500R002C00, V600R006C00, TE40 V500R002C00, V600R006C00, TE50 V500R002C00, V600R006C00, TE60 V100R001C10, V500R002C00, V600R006C00 have a memory leak vulnerability. The software does not release allocated memory properly when handling XML data. An authenticated, local attacker could upload crafted XML file repeatedly to cause memory leak and service abnormal.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-114236

Low

2026-10-21

Not applicable

No public exploit

storage/pkg/archive.ApplyLayer and ApplyUncompressedLayer may, when processing corrupt or malicious inputs, leak a file descriptor; unbounded repeated calls can exhaust the process’ file descriptor limit

CVE-2026-77205

Low

2026-10-13

Not applicable

No public exploit

Libreswan in FIPS mode has a vulnerability where badly formed received certificates are rejected, but not deleted from the NSS cache. As a result, any real certificates with the same serial number are rejected as well. This can be abused to lock out legitimate peers from connecting. The add_decoded_cert() function missed a call to CERT_DestroyCertificate() due to an incorrect fix for CVE-2026-14957. Sending bogus certificates with new serial numbers could prevent the real certificates with those serial numbers from connecting until the service has restarted.

CVE-2026-11811

Low

2026-08-10

Not applicable

No public exploit

The UpdateHub over-the-air update client's start_coap_client() in subsys/mgmt/updatehub/updatehub.c leaks the CoAP/DTLS socket descriptor on its connection-setup failure paths. The shared error: cleanup gated socket closing on a ret > 0 flag, but ret was set to -1 immediately after the socket was created, so when zsock_setsockopt() (DTLS) or zsock_connect() subsequently failed the gate was false and cleanup_connection() was never called. The open descriptor in the global ctx.sock was then overwritten by the next attempt, permanently leaking it from the socket / net_context pool until reboot. The failing setup path is reached every time the OTA client tries to contact the UpdateHub server and the connection cannot be established — driven automatically by the periodic autohandler() poll (and on demand via the updatehub_probe()/updatehub_update() API or the updatehub run shell command). The DTLS handshake/connect outcome is influenceable by a network or on-path attacker who drops, resets, or otherwise disrupts traffic to the server, and also fails naturally whenever the server is unreachable. Each failed attempt permanently leaks one descriptor; once the shared socket pool is exhausted, networking degrades device-wide until the device is rebooted, a denial-of-service condition. Severity is low because the leak rate is bounded by the configured OTA poll interval (default once per 24 hours), the effect is gradual and recovered by reboot, and only builds with the UpdateHub client enabled are affected. There is no memory-corruption, information-disclosure, or authentication impact.

CVE-2026-41637

Low

2026-07-22

Not applicable

No public exploit

In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, client terminated DNS-over-QUIC (DoQ) queries are not accounted properly by Unbound resulting in low-cost inflation of the waiting number of replies for already in-flight resolution queries. This results in degradation of resolution service for new clients for already in-flight queries. A malicious actor can exploit the vulnerability by issuing DoQ queries for query names that need resolution and proceeding on immediately terminating the query by one of STOP_SENDING/RESET_STREAM/CONNECTION_CLOSE QUIC frames. Those terminated DoQ queries are not properly counted for and keep inflating the number of waiting replies for in-flight queries. When the maximum is reached, it results in silent query drops for new clients needing resolution for already in-flight queries. This vulnerability needs Unbound to be compiled with DoQ support ('--with-libngtcp2') and the 'quic-port' to be configured for the listening interfaces. Additionally, a malicious actor needs access to multiple source IPs to bypass the by-default configured 'wait-limit' option.

CVE-2026-54786

Low

2026-07-01

Not applicable

No public exploit

Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2.

CVE-2026-45287

Low

2026-06-04

Not applicable

Proof of concept only

OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.0.17, `go.opentelemetry.io/otel/schema/v1.0` and `go.opentelemetry.io/otel/schema/v1.1` leaks one file descriptor on each successful `ParseFile` call. `ParseFile` opens the schema file and passes it to `Parse` without closing it; repeated parsing in a long-running process can exhaust the process file descriptor limit and cause denial of service. Exploitation depends on a consuming application exposing repeated schema parsing to an attacker-controlled path. Version 0.0.17 contains a patch for the issue.

CVE-2025-64734

Low

2025-11-18

Not applicable

No public exploit

Missing Release of Resource after Effective Lifetime (CWE-772) in the T21 Reader allows an attacker with physical access to the Reader to perform a denial-of-service attack against that specific reader, preventing cardholders from badging for entry. This issue affects Command Centre Server: 9.30 prior to vCR9.30.251028a (distributed in 9.30.2881 (MR3)), 9.20 prior to vCR9.20.251028a (distributed in 9.20.3265 (MR5)), 9.10 prior to vCR9.10.251028a (distributed in 9.10.4135 (MR8)), all versions of 9.00 and prior.

CVE-2025-61670

Low

2025-10-07

Not applicable

No public exploit

Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak. Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted<T>` type to a new `OwnedRooted<T>` type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted<T>`, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks. In migrating to `OwnedRooted<T>` the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the `OwnedRooted<T>` type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of `OwnedRooted<T>` vs `ManuallyRooted<T>` is that the `OwnedRooted<T>` type allocates host memory outside of the store. This means that if an `OwnedRooted<T>` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host. This led to a few distinct, but related, issues arising: A typo in the `wasmtime_val_unroot` function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a `wasmtime_{externref,anyref}_t` value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when `OwnedRooted<T>` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values. These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example `wasmtime_val_unroot` has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the `ExternRef`, `AnyRef`, and `Val` types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and `main` in the Wasmtime repository) include minor API updates to better accommodate the API semantic changes. The only known workaround at this time is to avoid using `externref` and `anyref` in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue.

CVE-2025-0036

Low

2025-06-10

Not applicable

No public exploit

In AMD Versal Adaptive SoC devices, the incorrect configuration of the SSS during runtime (post-boot) cryptographic operations could cause data to be incorrectly written to and read from invalid locations as well as returning incorrect cryptographic data.

CVE-2025-3864

Low

2025-05-28

Not applicable

No public exploit

Hackney fails to properly release HTTP connections to the pool after handling 307 Temporary Redirect responses. Remote attackers can exploit this to exhaust connection pools, causing denial of service in applications using the library. Fix for this issue has been included in 1.24.0 release.

CVE-2022-26354

Low

2022-03-16

Not applicable

No public exploit

A flaw was found in the vhost-vsock device of QEMU. In case of error, an invalid element was not detached from the virtqueue before freeing its memory, leading to memory leakage and other unexpected results. Affected QEMU versions <= 6.2.0.

CVE-2020-27351

Low

2020-12-10

Not applicable

No public exploit

Various memory and file descriptor leaks were found in apt-python files python/arfile.cc, python/tag.cc, python/tarfile.cc, aka GHSL-2020-170. This issue affects: python-apt 1.1.0~beta1 versions prior to 1.1.0~beta1ubuntu0.16.04.10; 1.6.5ubuntu0 versions prior to 1.6.5ubuntu0.4; 2.0.0ubuntu0 versions prior to 2.0.0ubuntu0.20.04.2; 2.1.3ubuntu1 versions prior to 2.1.3ubuntu1.1;

CVE-2019-19533

Low

2019-12-03

Not applicable

No public exploit

In the Linux kernel before 5.3.4, there is an info-leak bug that can be caused by a malicious USB device in the drivers/media/usb/ttusb-dec/ttusb_dec.c driver, aka CID-a10feaf8c464.

CVE-2017-17330

Low

2018-03-09

Not applicable

No public exploit

Huawei AR3200 V200R005C32; V200R006C10; V200R006C11; V200R007C00; V200R007C01; V200R007C02; V200R008C00; V200R008C10; V200R008C20; V200R008C30; NGFW Module V500R001C00; V500R001C20; V500R002C00 have a memory leak vulnerability. The software does not release allocated memory properly when parse XML element data. An authenticated attacker could upload a crafted XML file, successful exploit could cause the system service abnormal since run out of memory.

CVE-2017-17329

Low

2018-03-09

Not applicable

No public exploit

Huawei ViewPoint 8660 V100R008C03 have a memory leak vulnerability. The software does not release allocated memory properly when parse XML Schema data. An authenticated attacker could upload a crafted XML file, successful exploit could cause the system service abnormal since run out of memory.

CVE-2017-17141

Low

2018-03-05

Not applicable

No public exploit

Huawei S12700 V200R005C00; V200R006C00; V200R007C00; V200R007C01; V200R007C20; V200R008C00; V200R009C00;S1700 V200R006C10; V200R009C00;S2700 V100R006C03; V200R003C00; V200R005C00; V200R006C00; V200R006C10; V200R007C00; V200R007C00B050; V200R007C00SPC009T; V200R007C00SPC019T; V200R008C00; V200R009C00;S3700 V100R006C03;S5700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R003C02; V200R005C00; V200R005C01; V200R005C02; V200R005C03; V200R006C00; V200R007C00; V200R008C00; V200R009C00;S6700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R005C01; V200R005C02; V200R008C00; V200R009C00;S7700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R006C00; V200R006C01; V200R007C00; V200R007C01; V200R008C00; V200R008C06; V200R009C00;S9700 V200R001C00; V200R001C01; V200R002C00; V200R003C00; V200R005C00; V200R006C00; V200R007C00; V200R007C01; V200R008C00; V200R009C00 have a memory leak vulnerability. In some specific conditions, if attackers send specific malformed MPLS Service PING messages to the affected products, products do not release the memory when handling the packets. So successful exploit will result in memory leak of the affected products.

CVE-2017-17302

Low

2018-02-15

Not applicable

No public exploit

Huawei DP300 V500R002C00, RP200 V600R006C00, TE30 V100R001C10, V500R002C00, V600R006C00, TE40 V500R002C00, V600R006C00, TE50 V500R002C00, V600R006C00, TE60 V100R001C10, V500R002C00, V600R006C00 have a memory leak vulnerability. An authenticated, local attacker may craft and load some specific Certificate Revocation List(CRL) configuration files to the devices repeatedly. Due to not release allocated memory properly, successful exploit may result in memory leak and services abnormal.

CVE-2017-17289

Low

2018-02-15

Not applicable

No public exploit

Huawei DP300 V500R002C00, RP200 V500R002C00, V600R006C00, TE30 V100R001C10, V500R002C00, V600R006C00, TE40 V500R002C00, V600R006C00, TE50 V500R002C00, V600R006C00, TE60 V100R001C10, V500R002C00, V600R006C00 have a memory leak vulnerability. The software does not release allocated memory properly when handling XML data. An authenticated, local attacker could upload crafted XML file repeatedly to cause memory leak and service abnormal.