CWE-772
AllowedMissing Release of Resource after Effective Lifetime
Abstraction: Base · Status: Draft
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
567 vulnerabilities reference this CWE, most recent first.
GHSA-VV74-9HC2-QCPX
Vulnerability from github – Published: 2022-05-13 01:51 – Updated: 2022-05-13 01:51An issue was discovered in Bento4 1.5.1-627. There is a memory leak in AP4_DescriptorFactory::CreateDescriptorFromStream in Core/Ap4DescriptorFactory.cpp, as demonstrated by mp42hls.
{
"affected": [],
"aliases": [
"CVE-2018-20407"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-23T23:29:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Bento4 1.5.1-627. There is a memory leak in AP4_DescriptorFactory::CreateDescriptorFromStream in Core/Ap4DescriptorFactory.cpp, as demonstrated by mp42hls.",
"id": "GHSA-vv74-9hc2-qcpx",
"modified": "2022-05-13T01:51:02Z",
"published": "2022-05-13T01:51:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20407"
},
{
"type": "WEB",
"url": "https://github.com/axiomatic-systems/Bento4/issues/343"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VVP9-H8P2-XWFC
Vulnerability from github – Published: 2026-07-14 17:48 – Updated: 2026-07-14 17:48Impact
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_unrootfunction 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}_tvalue 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 accomodate the API semantic changes.
Patches
Wasmtime 37.0.2 has been released which fixes these issues. Users of 37.0.0 and 37.0.1 are recommended to upgrade. Users of 36.0.x and prior are unaffected and need not upgrade.
Workarounds
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.
Remediations
The Wasmtime project will be looking more closely into improving the situation around testing the C and C++ APIs of Wasmtime in the near future. For example we plan to integrate ASAN testing to discover leaks and errors earlier on in the development process. We're also going to look into expanding the test coverage of the C/C++ APIs to catch issues like this earlier on in development in the future.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime-c-api-impl"
},
"ranges": [
{
"events": [
{
"introduced": "37.0.0"
},
{
"fixed": "37.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wasmtime-bin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "37.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61670"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T17:48:35Z",
"nvd_published_at": "2025-10-07T19:15:38Z",
"severity": "LOW"
},
"details": "### Impact\n\nWasmtime 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.\n\nDevelopment of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted\u003cT\u003e` type to a new `OwnedRooted\u003cT\u003e` type. This change was integrated into Wasmtime\u0027s 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\u003cT\u003e`, 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.\n\nIn migrating to `OwnedRooted\u003cT\u003e` 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\u003cT\u003e` 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\u003cT\u003e` vs `ManuallyRooted\u003cT\u003e` is that the `OwnedRooted\u003cT\u003e` type allocates host memory outside of the store. This means that if an `OwnedRooted\u003cT\u003e` is leaked then destroying a store does not release this memory and it\u0027s a permanent memory leak on the host. This led to a few distinct, but related, issues arising:\n\n* 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.\n* 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.\n* 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\u003cT\u003e` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values.\n\nThese 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 accomodate the API semantic changes.\n\n### Patches\n\nWasmtime 37.0.2 has been released which fixes these issues. Users of 37.0.0 and 37.0.1 are recommended to upgrade. Users of 36.0.x and prior are unaffected and need not upgrade.\n\n### Workarounds\n\nThe 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\u0027s required for users to update to mitigate the leak issue.\n\n### Remediations\n\nThe Wasmtime project will be looking more closely into improving the situation around testing the C and C++ APIs of Wasmtime in the near future. For example we plan to integrate ASAN testing to discover leaks and errors earlier on in the development process. We\u0027re also going to look into expanding the test coverage of the C/C++ APIs to catch issues like this earlier on in development in the future.",
"id": "GHSA-vvp9-h8p2-xwfc",
"modified": "2026-07-14T17:48:35Z",
"published": "2026-07-14T17:48:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vvp9-h8p2-xwfc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61670"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/adff9d9d0f09569203709d5687e5a7dc8e1ad0a3"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/releases/tag/v37.0.2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime-bin/PYSEC-2025-268.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Wasmtime: Memory leak in C API with `externref` and `anyref` types"
}
GHSA-VWV5-298P-PW28
Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-06-30 03:36A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.
{
"affected": [],
"aliases": [
"CVE-2026-3104"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T14:16:36Z",
"severity": "HIGH"
},
"details": "A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain.\nThis issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.\nBIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.",
"id": "GHSA-vwv5-298p-pw28",
"modified": "2026-06-30T03:36:00Z",
"published": "2026-03-25T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3104"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6935"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-3104"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2451310"
},
{
"type": "WEB",
"url": "https://downloads.isc.org/isc/bind9/9.20.21"
},
{
"type": "WEB",
"url": "https://downloads.isc.org/isc/bind9/9.21.20"
},
{
"type": "WEB",
"url": "https://kb.isc.org/docs/cve-2026-3104"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-3104.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W28M-VF9V-7CM7
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42In ImageMagick 7.0.6-1, a memory leak vulnerability was found in the function ReadWMFImage in coders/wmf.c, which allows attackers to cause a denial of service in CloneDrawInfo in draw.c.
{
"affected": [],
"aliases": [
"CVE-2017-12428"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-04T10:29:00Z",
"severity": "HIGH"
},
"details": "In ImageMagick 7.0.6-1, a memory leak vulnerability was found in the function ReadWMFImage in coders/wmf.c, which allows attackers to cause a denial of service in CloneDrawInfo in draw.c.",
"id": "GHSA-w28m-vf9v-7cm7",
"modified": "2022-05-13T01:42:41Z",
"published": "2022-05-13T01:42:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12428"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/544"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-4019"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100145"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W2CQ-HJVV-8Q4H
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50There is a memory leak in the function WriteMSLImage of coders/msl.c in ImageMagick 7.0.8-13 Q16, and the function ProcessMSLScript of coders/msl.c in GraphicsMagick before 1.3.31.
{
"affected": [],
"aliases": [
"CVE-2018-18544"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-21T01:29:00Z",
"severity": "MODERATE"
},
"details": "There is a memory leak in the function WriteMSLImage of coders/msl.c in ImageMagick 7.0.8-13 Q16, and the function ProcessMSLScript of coders/msl.c in GraphicsMagick before 1.3.31.",
"id": "GHSA-w2cq-hjvv-8q4h",
"modified": "2022-05-13T01:50:42Z",
"published": "2022-05-13T01:50:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18544"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/1360"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4034-1"
},
{
"type": "WEB",
"url": "http://hg.code.sf.net/p/graphicsmagick/code/file/233618f8fe82/ChangeLog"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00034.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W3V7-4J7J-756R
Vulnerability from github – Published: 2022-05-13 01:52 – Updated: 2022-05-13 01:52ImageMagick 7.0.7-22 Q16 has memory leaks in the EncodeImageAttributes function in coders/json.c, as demonstrated by the ReadPSDLayersInternal function in coders/psd.c.
{
"affected": [],
"aliases": [
"CVE-2018-5358"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-12T09:29:00Z",
"severity": "MODERATE"
},
"details": "ImageMagick 7.0.7-22 Q16 has memory leaks in the EncodeImageAttributes function in coders/json.c, as demonstrated by the ReadPSDLayersInternal function in coders/psd.c.",
"id": "GHSA-w3v7-4j7j-756r",
"modified": "2022-05-13T01:52:47Z",
"published": "2022-05-13T01:52:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5358"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/939"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3681-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W55R-PJX8-29P7
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14ImageMagick 7.0.6-2 has a memory leak vulnerability in WritePDFImage in coders/pdf.c.
{
"affected": [],
"aliases": [
"CVE-2017-12662"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-07T21:29:00Z",
"severity": "HIGH"
},
"details": "ImageMagick 7.0.6-2 has a memory leak vulnerability in WritePDFImage in coders/pdf.c.",
"id": "GHSA-w55r-pjx8-29p7",
"modified": "2022-05-13T01:14:43Z",
"published": "2022-05-13T01:14:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12662"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/576"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/bd40cc5f53067322861b881485cbd70f509f3829"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100232"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W55W-49H8-P8XC
Vulnerability from github – Published: 2022-07-23 00:00 – Updated: 2022-07-30 00:00QPDF v8.4.2 was discovered to contain a heap buffer overflow via the function QPDF::processXRefStream. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.
{
"affected": [],
"aliases": [
"CVE-2022-34503"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-22T15:15:00Z",
"severity": "MODERATE"
},
"details": "QPDF v8.4.2 was discovered to contain a heap buffer overflow via the function QPDF::processXRefStream. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.",
"id": "GHSA-w55w-49h8-p8xc",
"modified": "2022-07-30T00:00:42Z",
"published": "2022-07-23T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34503"
},
{
"type": "WEB",
"url": "https://github.com/qpdf/qpdf/issues/701"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W573-9FFJ-6FF9
Vulnerability from github – Published: 2026-06-08 23:01 – Updated: 2026-06-12 19:29netty_unix_socket_recvFd sets msg_control to char control[CMSG_SPACE(sizeof(int))] (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check cmsg->cmsg_len == CMSG_LEN(sizeof(int)) (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-epoll"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-kqueue"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-kqueue"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-epoll"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45536"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:01:33Z",
"nvd_published_at": "2026-06-12T15:16:27Z",
"severity": "MODERATE"
},
"details": "netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) \u2014 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg-\u003ecmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking \u2192 EAGAIN \u2192 Java maps to 0 \u2192 read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).",
"id": "GHSA-w573-9ffj-6ff9",
"modified": "2026-06-12T19:29:26Z",
"published": "2026-06-08T23:01:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-w573-9ffj-6ff9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45536"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty: Unix-socket fd receive leaks descriptors when peer sends two at once"
}
GHSA-W5CR-FRPH-HW7F
Vulnerability from github – Published: 2021-08-25 21:01 – Updated: 2021-05-25 20:52An issue was discovered in the rkyv crate before 0.6.0 for Rust. When an archive is created via serialization, the archive content may contain uninitialized values of certain parts of a struct.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "rkyv"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-31919"
],
"database_specific": {
"cwe_ids": [
"CWE-772",
"CWE-908"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-25T20:52:53Z",
"nvd_published_at": "2021-04-30T03:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the rkyv crate before 0.6.0 for Rust. When an archive is created via serialization, the archive content may contain uninitialized values of certain parts of a struct.",
"id": "GHSA-w5cr-frph-hw7f",
"modified": "2021-05-25T20:52:53Z",
"published": "2021-08-25T21:01:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31919"
},
{
"type": "WEB",
"url": "https://github.com/djkoloski/rkyv/issues/113"
},
{
"type": "WEB",
"url": "https://github.com/djkoloski/rkyv/commit/9c65ae9c2c67dd949b5c3aba9b8eba6da802ab7e"
},
{
"type": "WEB",
"url": "https://github.com/djkoloski/rkyv/commit/f141b560523a20557db6540576d153010bd18712"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0054.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Use of uninitialized buffer in rkyv"
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
Mitigation
It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
Mitigation MIT-47
Strategy: Resource Limitation
- Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.