CWE-401
AllowedMissing Release of Memory after Effective Lifetime
Abstraction: Variant · Status: Draft
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
2133 vulnerabilities reference this CWE, most recent first.
GHSA-948P-87WR-RW9M
Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-23 12:00In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization.
{
"affected": [],
"aliases": [
"CVE-2022-41624"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-19T22:15:00Z",
"severity": "HIGH"
},
"details": "In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization.",
"id": "GHSA-948p-87wr-rw9m",
"modified": "2022-10-23T12:00:26Z",
"published": "2022-10-20T12:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41624"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K43024307"
}
],
"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-94C2-F29F-CQQQ
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 21:31In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
If ret_val is non-zero, then free the iocbq request structure.
{
"affected": [],
"aliases": [
"CVE-2022-50027"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix possible memory leak when failing to issue CMF WQE\n\nThere is no corresponding free routine if lpfc_sli4_issue_wqe fails to\nissue the CMF WQE in lpfc_issue_cmf_sync_wqe.\n\nIf ret_val is non-zero, then free the iocbq request structure.",
"id": "GHSA-94c2-f29f-cqqq",
"modified": "2025-11-13T21:31:17Z",
"published": "2025-06-18T12:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50027"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f67dc7970bce3529edce93a0a14234d88b3fcd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4eb7a1beff03836d3df271cd23b790884e3facb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c8e2e607270a368834a0ef72aa82d970f89c596"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-94G7-4R7X-4RFV
Vulnerability from github – Published: 2023-01-12 21:30 – Updated: 2025-11-25 21:32A potential memory leak issue was discovered in SDL2 in GLES_CreateTexture() function in SDL_render_gles.c. The vulnerability allows an attacker to cause a denial of service attack. The vulnerability affects SDL2 v2.0.4 and above. SDL-1.x are not affected.
{
"affected": [],
"aliases": [
"CVE-2022-4743"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-12T19:15:00Z",
"severity": "HIGH"
},
"details": "A potential memory leak issue was discovered in SDL2 in GLES_CreateTexture() function in SDL_render_gles.c. The vulnerability allows an attacker to cause a denial of service attack. The vulnerability affects SDL2 v2.0.4 and above. SDL-1.x are not affected.",
"id": "GHSA-94g7-4r7x-4rfv",
"modified": "2025-11-25T21:32:02Z",
"published": "2023-01-12T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4743"
},
{
"type": "WEB",
"url": "https://github.com/libsdl-org/SDL/pull/6269"
},
{
"type": "WEB",
"url": "https://github.com/libsdl-org/SDL/commit/00b67f55727bc0944c3266e2b875440da132ce4b"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2022-4743"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2156290"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00008.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/11/msg00024.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-18"
}
],
"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-94JM-9M2W-WFHH
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30In the Linux kernel, the following vulnerability has been resolved:
most: core: fix leak on early registration failure
A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface.
Fix up also the first error path so that the interface is always released on errors.
{
"affected": [],
"aliases": [
"CVE-2026-43317"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmost: core: fix leak on early registration failure\n\nA recent commit fixed a resource leak on early registration failures but\nfor some reason left out the first error path which still leaks the\nresources associated with the interface.\n\nFix up also the first error path so that the interface is always\nreleased on errors.",
"id": "GHSA-94jm-9m2w-wfhh",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43317"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c198c272f9c9213b0fdf6b4a879f445c574f416"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5fd4396c2e48e90cc2597a86c18227d56ea845f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbfe49ffb892bddf32c34bea95b7ff0fc30affb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1ba620f9e8d7291f80c0554e4b820f5fb30e819"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-94M8-5MHQ-PH6M
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2024-10-22 18:32In the Linux kernel, the following vulnerability has been resolved:
nvdimm: Fix devs leaks in scan_labels()
scan_labels() leaks memory when label scanning fails and it falls back to just creating a default "seed" namespace for userspace to configure. Root can force the kernel to leak memory.
Allocate the minimum resources unconditionally and release them when unneeded to avoid the memory leak.
A kmemleak reports: unreferenced object 0xffff88800dda1980 (size 16): comm "kworker/u10:5", pid 69, jiffies 4294671781 hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<00000000c5dea560>] __kmalloc+0x32c/0x470 [<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm] [<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm] [<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] [<00000000a5f3da2e>] really_probe+0xc6/0x390 [<00000000129e2a69>] __driver_probe_device+0x78/0x150 [<000000002dfed28b>] driver_probe_device+0x1e/0x90 [<00000000e7048de2>] __device_attach_driver+0x85/0x110 [<0000000032dca295>] bus_for_each_drv+0x85/0xe0 [<00000000391c5a7d>] __device_attach+0xbe/0x1e0 [<0000000026dabec0>] bus_probe_device+0x94/0xb0 [<00000000c590d936>] device_add+0x656/0x870 [<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm] [<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110 [<00000000e201f4b0>] process_one_work+0x1ee/0x600 [<000000006d90d5a9>] worker_thread+0x183/0x350
{
"affected": [],
"aliases": [
"CVE-2024-47755"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm: Fix devs leaks in scan_labels()\n\nscan_labels() leaks memory when label scanning fails and it falls back\nto just creating a default \"seed\" namespace for userspace to configure.\nRoot can force the kernel to leak memory.\n\nAllocate the minimum resources unconditionally and release them when\nunneeded to avoid the memory leak.\n\nA kmemleak reports:\nunreferenced object 0xffff88800dda1980 (size 16):\n comm \"kworker/u10:5\", pid 69, jiffies 4294671781\n hex dump (first 16 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n [\u003c00000000c5dea560\u003e] __kmalloc+0x32c/0x470\n [\u003c000000009ed43c83\u003e] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm]\n [\u003c000000000e07a65c\u003e] nd_region_probe+0xfe/0x210 [libnvdimm]\n [\u003c000000007b79ce5f\u003e] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]\n [\u003c00000000a5f3da2e\u003e] really_probe+0xc6/0x390\n [\u003c00000000129e2a69\u003e] __driver_probe_device+0x78/0x150\n [\u003c000000002dfed28b\u003e] driver_probe_device+0x1e/0x90\n [\u003c00000000e7048de2\u003e] __device_attach_driver+0x85/0x110\n [\u003c0000000032dca295\u003e] bus_for_each_drv+0x85/0xe0\n [\u003c00000000391c5a7d\u003e] __device_attach+0xbe/0x1e0\n [\u003c0000000026dabec0\u003e] bus_probe_device+0x94/0xb0\n [\u003c00000000c590d936\u003e] device_add+0x656/0x870\n [\u003c000000003d69bfaa\u003e] nd_async_device_register+0xe/0x50 [libnvdimm]\n [\u003c000000003f4c52a4\u003e] async_run_entry_fn+0x2e/0x110\n [\u003c00000000e201f4b0\u003e] process_one_work+0x1ee/0x600\n [\u003c000000006d90d5a9\u003e] worker_thread+0x183/0x350",
"id": "GHSA-94m8-5mhq-ph6m",
"modified": "2024-10-22T18:32:10Z",
"published": "2024-10-21T15:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47755"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18a672c62d735744c6340eb3f5e58934a5d34cf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45db20bdb5695d06478d35e05fb2550441bed890"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c2aa6b1f565d2fc1ec11a6e9e8336ce37a6426"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/939053737edb49ba5bdc5846acb45f11d15b7ab4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdf0dfb3d183bbe0d0b6a6622c53d105074ad384"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-94RJ-FRV4-2P83
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36In process of C2SoftVorbisDec.cpp, there is a possible resource exhaustion due to a memory leak. 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-154302257
{
"affected": [],
"aliases": [
"CVE-2020-27038"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T17:15:00Z",
"severity": "MODERATE"
},
"details": "In process of C2SoftVorbisDec.cpp, there is a possible resource exhaustion due to a memory leak. 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-154302257",
"id": "GHSA-94rj-frv4-2p83",
"modified": "2022-05-24T17:36:30Z",
"published": "2022-05-24T17:36:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27038"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2020-12-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-952P-3M9P-PRPF
Vulnerability from github – Published: 2022-05-12 00:01 – Updated: 2022-05-20 00:00The HTTP Server in PRIMEUR SPAZIO 2.5.1.954 (File Transfer) allows an unauthenticated attacker to obtain sensitive data (related to the content of transferred files) via a crafted HTTP request.
{
"affected": [],
"aliases": [
"CVE-2022-29932"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-11T14:15:00Z",
"severity": "HIGH"
},
"details": "The HTTP Server in PRIMEUR SPAZIO 2.5.1.954 (File Transfer) allows an unauthenticated attacker to obtain sensitive data (related to the content of transferred files) via a crafted HTTP request.",
"id": "GHSA-952p-3m9p-prpf",
"modified": "2022-05-20T00:00:52Z",
"published": "2022-05-12T00:01:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29932"
},
{
"type": "WEB",
"url": "https://github.com/Off3nS3c/CVE-2022-29932/blob/main/Proof-of-Concept.md"
},
{
"type": "WEB",
"url": "https://www.primeur.com/managed-file-transfer"
}
],
"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"
}
]
}
GHSA-95G8-7CPF-MP2Q
Vulnerability from github – Published: 2024-07-29 15:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix memory leak in nfs4_set_security_label
We leak nfs_fattr and nfs4_label every time we set a security xattr.
{
"affected": [],
"aliases": [
"CVE-2024-41076"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T15:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Fix memory leak in nfs4_set_security_label\n\nWe leak nfs_fattr and nfs4_label every time we set a security xattr.",
"id": "GHSA-95g8-7cpf-mp2q",
"modified": "2025-11-04T00:31:02Z",
"published": "2024-07-29T15:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41076"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-95PH-5WPX-W6GQ
Vulnerability from github – Published: 2024-01-16 18:31 – Updated: 2024-01-23 18:31A GPU kernel can read sensitive data from another GPU kernel (even from another user or app) through an optimized GPU memory region called local memory on various architectures.
{
"affected": [],
"aliases": [
"CVE-2023-4969"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-16T17:15:08Z",
"severity": "MODERATE"
},
"details": "A GPU kernel can read sensitive data from another GPU kernel (even from another user or app) through an optimized GPU memory region called _local memory_ on various architectures.",
"id": "GHSA-95ph-5wpx-w6gq",
"modified": "2024-01-23T18:31:11Z",
"published": "2024-01-16T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4969"
},
{
"type": "WEB",
"url": "https://blog.trailofbits.com"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/446598"
},
{
"type": "WEB",
"url": "https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#_fundamental_memory_regions"
},
{
"type": "WEB",
"url": "https://registry.khronos.org/vulkan/specs/1.3-extensions/html/index.html"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/446598"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-962Q-HWM5-52X5
Vulnerability from github – Published: 2026-05-18 20:17 – Updated: 2026-06-09 10:58Summary
The custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory.
Details
The vulnerable implementation is in pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11. New keys are appended to a ConcurrentLinkedQueue, and eviction only runs inside put() when map.size() > capacity.
The remove() method removes the key from the ConcurrentHashMap but leaves the key in the queue. Because evictIfNeeded() only checks map.size() > capacity, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.
This pattern is reachable from pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66, where cleanupConnectionBufMapping removes entries from bufConn and activeConnections, and removeBufferMapping removes entries from bufToBuf. In normal TLS connection lifecycles, those removals happen frequently.
PoC
Local testing with a small Java reproducer showed queue growth continuing after removals and eventually reached OutOfMemoryError, which matches the code-level leak mechanism described above.
Use a vulnerable Java agent build from v0.0.0-rc.2+build.2 or any later release that still contains the change. Start any JVM process instrumented with OBI's Java TLS support, then generate a large number of short-lived TLS handshakes.
One local reproducer is:
git checkout v0.0.0-rc.2+build.2
make build
Start a simple TLS server:
openssl req -x509 -newkey rsa:2048 -nodes -keyout /tmp/key.pem -out /tmp/cert.pem -subj '/CN=localhost' -days 1
openssl s_server -accept 9443 -key /tmp/key.pem -cert /tmp/cert.pem -quiet
Run an instrumented JVM client that repeatedly opens and closes TLS connections:
// save as /tmp/TLSChurn.java
import javax.net.ssl.*;
import java.net.Socket;
public class TLSChurn {
public static void main(String[] args) throws Exception {
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, new TrustManager[]{new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }
public void checkClientTrusted(java.security.cert.X509Certificate[] c, String a) {}
public void checkServerTrusted(java.security.cert.X509Certificate[] c, String a) {}
}}, new java.security.SecureRandom());
SSLSocketFactory f = ctx.getSocketFactory();
for (;;) {
try (Socket s = f.createSocket("127.0.0.1", 9443)) {
s.getOutputStream().write("x".getBytes());
} catch (Exception ignored) {}
}
}
}
Compile and run:
javac /tmp/TLSChurn.java
java TLSChurn
Attach the vulnerable OBI Java instrumentation to the JVM. Over time, heap usage in the OBI Java agent process grows even though live connection counts remain bounded. A heap dump will show large retention from ConcurrentLinkedQueue nodes owned by CappedConcurrentHashMap.
Impact
This issue causes an availability loss in instrumented Java workloads that use OBI's TLS instrumentation. Repeated connection setup and teardown can grow the retained queue until the Java helper experiences long GC pauses or exhausts heap memory with OutOfMemoryError.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/obi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45682"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T20:17:33Z",
"nvd_published_at": "2026-06-02T16:16:42Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe custom `CappedConcurrentHashMap` introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory.\n\n### Details\n\nThe vulnerable implementation is in [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11). New keys are appended to a `ConcurrentLinkedQueue`, and eviction only runs inside `put()` when `map.size() \u003e capacity`.\n\nThe `remove()` method removes the key from the `ConcurrentHashMap` but leaves the key in the queue. Because `evictIfNeeded()` only checks `map.size() \u003e capacity`, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.\n\nThis pattern is reachable from [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66), where `cleanupConnectionBufMapping` removes entries from `bufConn` and `activeConnections`, and `removeBufferMapping` removes entries from `bufToBuf`. In normal TLS connection lifecycles, those removals happen frequently.\n\n### PoC\n\nLocal testing with a small Java reproducer showed queue growth continuing after removals and eventually reached `OutOfMemoryError`, which matches the code-level leak mechanism described above.\n\nUse a vulnerable Java agent build from `v0.0.0-rc.2+build.2` or any later release that still contains the change. Start any JVM process instrumented with OBI\u0027s Java TLS support, then generate a large number of short-lived TLS handshakes.\n\nOne local reproducer is:\n\n```bash\ngit checkout v0.0.0-rc.2+build.2\nmake build\n```\n\nStart a simple TLS server:\n\n```bash\nopenssl req -x509 -newkey rsa:2048 -nodes -keyout /tmp/key.pem -out /tmp/cert.pem -subj \u0027/CN=localhost\u0027 -days 1\nopenssl s_server -accept 9443 -key /tmp/key.pem -cert /tmp/cert.pem -quiet\n```\n\nRun an instrumented JVM client that repeatedly opens and closes TLS connections:\n\n```java\n// save as /tmp/TLSChurn.java\nimport javax.net.ssl.*;\nimport java.net.Socket;\n\npublic class TLSChurn {\n public static void main(String[] args) throws Exception {\n SSLContext ctx = SSLContext.getInstance(\"TLS\");\n ctx.init(null, new TrustManager[]{new X509TrustManager() {\n public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }\n public void checkClientTrusted(java.security.cert.X509Certificate[] c, String a) {}\n public void checkServerTrusted(java.security.cert.X509Certificate[] c, String a) {}\n }}, new java.security.SecureRandom());\n\n SSLSocketFactory f = ctx.getSocketFactory();\n for (;;) {\n try (Socket s = f.createSocket(\"127.0.0.1\", 9443)) {\n s.getOutputStream().write(\"x\".getBytes());\n } catch (Exception ignored) {}\n }\n }\n}\n```\n\nCompile and run:\n\n```bash\njavac /tmp/TLSChurn.java\njava TLSChurn\n```\n\nAttach the vulnerable OBI Java instrumentation to the JVM. Over time, heap usage in the OBI Java agent process grows even though live connection counts remain bounded. A heap dump will show large retention from `ConcurrentLinkedQueue` nodes owned by `CappedConcurrentHashMap`.\n\n### Impact\n\nThis issue causes an availability loss in instrumented Java workloads that use OBI\u0027s TLS instrumentation. Repeated connection setup and teardown can grow the retained queue until the Java helper experiences long GC pauses or exhausts heap memory with `OutOfMemoryError`.",
"id": "GHSA-962q-hwm5-52x5",
"modified": "2026-06-09T10:58:45Z",
"published": "2026-05-18T20:17:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-962q-hwm5-52x5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45682"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry eBPF Instrumentation: CappedConcurrentHashMap leaks keys after removals"
}
Mitigation MIT-41
Strategy: Libraries or Frameworks
- Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
- For example, glibc in Linux provides protection against free of invalid pointers.
- When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
- To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
Mitigation
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation
Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
No CAPEC attack patterns related to this CWE.