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.
2014 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-965C-2M8V-WCJH
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
nfs4: Fix kmemleak when allocate slot failed
If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
{
"affected": [],
"aliases": [
"CVE-2022-49927"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs4: Fix kmemleak when allocate slot failed\n\nIf one of the slot allocate failed, should cleanup all the other\nallocated slots, otherwise, the allocated slots will leak:\n\n unreferenced object 0xffff8881115aa100 (size 64):\n comm \"\"mount.nfs\"\", pid 679, jiffies 4294744957 (age 115.037s)\n hex dump (first 32 bytes):\n 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u003c000000007a4c434a\u003e] nfs4_find_or_create_slot+0x8e/0x130\n [\u003c000000005472a39c\u003e] nfs4_realloc_slot_table+0x23f/0x270\n [\u003c00000000cd8ca0eb\u003e] nfs40_init_client+0x4a/0x90\n [\u003c00000000128486db\u003e] nfs4_init_client+0xce/0x270\n [\u003c000000008d2cacad\u003e] nfs4_set_client+0x1a2/0x2b0\n [\u003c000000000e593b52\u003e] nfs4_create_server+0x300/0x5f0\n [\u003c00000000e4425dd2\u003e] nfs4_try_get_tree+0x65/0x110\n [\u003c00000000d3a6176f\u003e] vfs_get_tree+0x41/0xf0\n [\u003c0000000016b5ad4c\u003e] path_mount+0x9b3/0xdd0\n [\u003c00000000494cae71\u003e] __x64_sys_mount+0x190/0x1d0\n [\u003c000000005d56bdec\u003e] do_syscall_64+0x35/0x80\n [\u003c00000000687c9ae4\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0",
"id": "GHSA-965c-2m8v-wcjh",
"modified": "2025-05-07T15:31:28Z",
"published": "2025-05-01T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49927"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401"
}
],
"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-9686-WRHG-JJG6
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
md/raid1: fix memory leak in raid1_run()
raid1_run() calls setup_conf() which registers a thread via md_register_thread(). If raid1_set_limits() fails, the previously registered thread is not unregistered, resulting in a memory leak of the md_thread structure and the thread resource itself.
Add md_unregister_thread() to the error path to properly cleanup the thread, which aligns with the error handling logic of other paths in this function.
Compile tested only. Issue found using a prototype static analysis tool and code review.
{
"affected": [],
"aliases": [
"CVE-2026-45888"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: fix memory leak in raid1_run()\n\nraid1_run() calls setup_conf() which registers a thread via\nmd_register_thread(). If raid1_set_limits() fails, the previously\nregistered thread is not unregistered, resulting in a memory leak\nof the md_thread structure and the thread resource itself.\n\nAdd md_unregister_thread() to the error path to properly cleanup\nthe thread, which aligns with the error handling logic of other paths\nin this function.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.",
"id": "GHSA-9686-wrhg-jjg6",
"modified": "2026-06-25T21:31:20Z",
"published": "2026-05-27T15:33:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45888"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6abc7d5dcf0ee0f85e16e41c87fbd06231f28753"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b37588b0282a2b3cdda9db1d53712745ce66dea0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c94fd6e8a71efd047ff36930e840f3c25679e136"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec10e3dc93994b87adf7c759a4639fe34013989a"
}
],
"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-9697-GFV8-47R6
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-05-07 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix drm_edid leak in amdgpu_dm
[WHAT] When a sink is connected, aconnector->drm_edid was overwritten without freeing the previous allocation, causing a memory leak on resume.
[HOW] Free the previous drm_edid before updating it.
(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)
{
"affected": [],
"aliases": [
"CVE-2026-31461"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix drm_edid leak in amdgpu_dm\n\n[WHAT]\nWhen a sink is connected, aconnector-\u003edrm_edid was overwritten without\nfreeing the previous allocation, causing a memory leak on resume.\n\n[HOW]\nFree the previous drm_edid before updating it.\n\n(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)",
"id": "GHSA-9697-gfv8-47r6",
"modified": "2026-05-07T21:30:24Z",
"published": "2026-04-22T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31461"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37c2caa167b0b8aca4f74c32404c5288b876a2a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52db857e94b9be4e6315586602b0257d1d2b165a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb95595194e4755b62360aa821f40a79b0953105"
}
],
"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-96C7-C73H-J4WW
Vulnerability from github – Published: 2023-05-23 21:30 – Updated: 2024-03-07 21:30Teeworlds v0.7.5 was discovered to contain memory leaks.
{
"affected": [],
"aliases": [
"CVE-2023-31517"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-23T20:15:09Z",
"severity": "HIGH"
},
"details": "Teeworlds v0.7.5 was discovered to contain memory leaks.",
"id": "GHSA-96c7-c73h-j4ww",
"modified": "2024-03-07T21:30:20Z",
"published": "2023-05-23T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31517"
},
{
"type": "WEB",
"url": "https://gist.github.com/manba-bryant/9ca95d69c65f4d2c55946932c946fb9b"
},
{
"type": "WEB",
"url": "https://www.redpacketsecurity.com/teeworlds-denial-of-service-cve-2023-31517"
},
{
"type": "WEB",
"url": "http://teeworlds.com"
}
],
"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-96GV-MMP8-MQX5
Vulnerability from github – Published: 2024-12-02 15:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix accept_queue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release
Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30
{
"affected": [],
"aliases": [
"CVE-2024-53119"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-02T14:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix accept_queue memory leak\n\nAs the final stages of socket destruction may be delayed, it is possible\nthat virtio_transport_recv_listen() will be called after the accept_queue\nhas been flushed, but before the SOCK_DONE flag has been set. As a result,\nsockets enqueued after the flush would remain unremoved, leading to a\nmemory leak.\n\nvsock_release\n __vsock_release\n lock\n virtio_transport_release\n virtio_transport_close\n schedule_delayed_work(close_work)\n sk_shutdown = SHUTDOWN_MASK\n(!) flush accept_queue\n release\n virtio_transport_recv_pkt\n vsock_find_bound_socket\n lock\n if flag(SOCK_DONE) return\n virtio_transport_recv_listen\n child = vsock_create_connected\n (!) vsock_enqueue_accept(child)\n release\nclose_work\n lock\n virtio_transport_do_close\n set_flag(SOCK_DONE)\n virtio_transport_remove_sock\n vsock_remove_sock\n vsock_remove_bound\n release\n\nIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() during\nsocket destruction.\n\nunreferenced object 0xffff888109e3f800 (size 2040):\n comm \"kworker/5:2\", pid 371, jiffies 4294940105\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............\n backtrace (crc 9e5f4e84):\n [\u003cffffffff81418ff1\u003e] kmem_cache_alloc_noprof+0x2c1/0x360\n [\u003cffffffff81d27aa0\u003e] sk_prot_alloc+0x30/0x120\n [\u003cffffffff81d2b54c\u003e] sk_alloc+0x2c/0x4b0\n [\u003cffffffff81fe049a\u003e] __vsock_create.constprop.0+0x2a/0x310\n [\u003cffffffff81fe6d6c\u003e] virtio_transport_recv_pkt+0x4dc/0x9a0\n [\u003cffffffff81fe745d\u003e] vsock_loopback_work+0xfd/0x140\n [\u003cffffffff810fc6ac\u003e] process_one_work+0x20c/0x570\n [\u003cffffffff810fce3f\u003e] worker_thread+0x1bf/0x3a0\n [\u003cffffffff811070dd\u003e] kthread+0xdd/0x110\n [\u003cffffffff81044fdd\u003e] ret_from_fork+0x2d/0x50\n [\u003cffffffff8100785a\u003e] ret_from_fork_asm+0x1a/0x30",
"id": "GHSA-96gv-mmp8-mqx5",
"modified": "2025-11-04T00:32:09Z",
"published": "2024-12-02T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53119"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-96J4-P2P4-VFGJ
Vulnerability from github – Published: 2023-09-27 18:30 – Updated: 2024-01-25 18:30A vulnerability in the memory buffer of Cisco Wireless LAN Controller (WLC) AireOS Software could allow an unauthenticated, adjacent attacker to cause memory leaks that could eventually lead to a device reboot.
This vulnerability is due to memory leaks caused by multiple clients connecting under specific conditions. An attacker could exploit this vulnerability by causing multiple wireless clients to attempt to connect to an access point (AP) on an affected device. A successful exploit could allow the attacker to cause the affected device to reboot after a significant amount of time, resulting in a denial of service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2023-20251"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-27T18:15:11Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the memory buffer of Cisco Wireless LAN Controller (WLC) AireOS Software could allow an unauthenticated, adjacent attacker to cause memory leaks that could eventually lead to a device reboot.\n\n This vulnerability is due to memory leaks caused by multiple clients connecting under specific conditions. An attacker could exploit this vulnerability by causing multiple wireless clients to attempt to connect to an access point (AP) on an affected device. A successful exploit could allow the attacker to cause the affected device to reboot after a significant amount of time, resulting in a denial of service (DoS) condition.",
"id": "GHSA-96j4-p2p4-vfgj",
"modified": "2024-01-25T18:30:44Z",
"published": "2023-09-27T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20251"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cbw-dos-YSmbUqX3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9729-XJVH-4QP8
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback
After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed.
It has been seen after hours of usage of a graphics application or using kmemleak:
unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54
{
"affected": [],
"aliases": [
"CVE-2026-43269"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback\n\nAfter several commits, the slab memory increases. Some drm_crtc_commit\nobjects are not freed. The atomic_destroy_state callback only put the\nframebuffer. Use the __drm_atomic_helper_plane_destroy_state() function\nto put all the objects that are no longer needed.\n\nIt has been seen after hours of usage of a graphics application or using\nkmemleak:\n\nunreferenced object 0xc63a6580 (size 64):\n comm \"egt_basic\", pid 171, jiffies 4294940784\n hex dump (first 32 bytes):\n 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:.\n 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:.\n backtrace (crc c25aa925):\n kmemleak_alloc+0x34/0x3c\n __kmalloc_cache_noprof+0x150/0x1a4\n drm_atomic_helper_setup_commit+0x1e8/0x7bc\n drm_atomic_helper_commit+0x3c/0x15c\n drm_atomic_commit+0xc0/0xf4\n drm_atomic_helper_set_config+0x84/0xb8\n drm_mode_setcrtc+0x32c/0x810\n drm_ioctl+0x20c/0x488\n sys_ioctl+0x14c/0xc20\n ret_fast_syscall+0x0/0x54",
"id": "GHSA-9729-xjvh-4qp8",
"modified": "2026-05-08T21:31:21Z",
"published": "2026-05-06T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43269"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/082271e364a3205598c2e4e6233a9f49ce7941cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25e832a7830740e72103eb0b527680a4b64bbcb3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e64e78f4a70e3f6ac8fe5a7071f08ffd25a2489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5718d98976ad6b9700e5a6afec67fc47a8a92580"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57fa3487acfa3467405f8506b94682abd96e7393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d4e91ab97fda64e8cf9c8881cc3b4da026bd849"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec40702029b08ee8d5f5b03303d64a10e74a957b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f12352471061df83a36edf54bbb16284793284e4"
}
],
"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"
}
]
}
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.