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.
2187 vulnerabilities reference this CWE, most recent first.
GHSA-64WP-HFMX-H9XX
Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2022-05-24 17:05An issue was discovered in GPAC version 0.8.0 and 0.9.0-development-20191109. There are memory leaks in metx_New in isomedia/box_code_base.c and abst_Read in isomedia/box_code_adobe.c.
{
"affected": [],
"aliases": [
"CVE-2019-20171"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-31T00:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in GPAC version 0.8.0 and 0.9.0-development-20191109. There are memory leaks in metx_New in isomedia/box_code_base.c and abst_Read in isomedia/box_code_adobe.c.",
"id": "GHSA-64wp-hfmx-h9xx",
"modified": "2022-05-24T17:05:25Z",
"published": "2022-05-24T17:05:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20171"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/issues/1337"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/01/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-655C-8JCM-3JQH
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 15:30In the Linux kernel, the following vulnerability has been resolved:
gpio: mvebu: fix irq domain leak
Uwe Kleine-König pointed out we still have one resource leak in the mvebu driver triggered on driver detach. Let's address it with a custom devm action.
{
"affected": [],
"aliases": [
"CVE-2023-53579"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mvebu: fix irq domain leak\n\nUwe Kleine-K\u00f6nig pointed out we still have one resource leak in the mvebu\ndriver triggered on driver detach. Let\u0027s address it with a custom devm\naction.",
"id": "GHSA-655c-8jcm-3jqh",
"modified": "2026-02-10T15:30:20Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53579"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44e2afbf650f3264519643fcc9e6b4d2f6e8d547"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/644ee70267a934be27370f9aa618b29af7290544"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b19e90521286a03bc3793fd598f20277a8f99c85"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9b791d8362359d241b4e8f4b4767c681ffdb6ef"
}
],
"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-65G2-8FCX-V5PC
Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2025-03-27 21:31libming v0.4.8 was discovered to contain a memory leak via the parseSWF_ENABLEDEBUGGER2 function.
{
"affected": [],
"aliases": [
"CVE-2025-29483"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T15:15:59Z",
"severity": "MODERATE"
},
"details": "libming v0.4.8 was discovered to contain a memory leak via the parseSWF_ENABLEDEBUGGER2 function.",
"id": "GHSA-65g2-8fcx-v5pc",
"modified": "2025-03-27T21:31:20Z",
"published": "2025-03-27T15:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29483"
},
{
"type": "WEB",
"url": "https://github.com/libming/libming/issues/330"
}
],
"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-65JJ-FMW8-468Q
Vulnerability from github – Published: 2026-07-02 20:12 – Updated: 2026-07-02 20:12Am I affected
You are affected if:
- You run
zebradup to and includingv4.4.1. - Your node accepts inbound P2P connections (
network.listen_addris set, which is the default). - Your node's mempool is active (node is synced near the chain tip).
All default configurations are affected.
Summary
The mempool download pipeline's cancel_handles map retains entries for transactions whose verification times out at the outer RATE_LIMIT_DELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancel_handles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.
Details
Downloads::poll_next() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task:
Ok(Ok(...)): success. Callscancel_handles.remove(&tx.transaction.id). Correct.Ok(Err(...)): verification error. Callscancel_handles.remove(&hash). Correct.Err(elapsed): outer timeout. ReturnsErr(elapsed)without removing anything. Bug.
tokio::time::error::Elapsed has no payload, so the timed-out transaction's UnminedTxId is unrecoverable from the error. The consumer at zebrad/src/components/mempool.rs:663-672 explicitly acknowledges this gap with a TODO comment.
The only cleanup paths for cancel_handles are cancel(mined_ids) (removes entries matching mined transaction IDs; attacker transactions are never mined) and cancel_all() (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.
For direct tx pushes (Gossip::Tx), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).
Patches
The fix preserves the UnminedTxId through the timeout error path: wrap the timeout future so the spawned task's outer error carries the txid (e.g., Err((txid, elapsed))). In Downloads::poll_next(), on the timeout arm, call cancel_handles.remove(&txid).
Workarounds
There is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.
Impact
Gradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.
Credit
Reported by @AnticsDecoded via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.4.1"
},
"package": {
"ecosystem": "crates.io",
"name": "zebrad"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52734"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T20:12:35Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default).\n3. Your node\u0027s mempool is active (node is synced near the chain tip).\n\nAll default configurations are affected.\n\n### Summary\n\nThe mempool download pipeline\u0027s `cancel_handles` map retains entries for transactions whose verification times out at the outer `RATE_LIMIT_DELAY` (73-second) boundary. The `tokio::time::error::Elapsed` error carries no payload, so the transaction ID is unrecoverable and the corresponding `cancel_handles` entry (including the full `Gossip::Tx(UnminedTx)`, up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.\n\n### Details\n\n`Downloads::poll_next()` at `zebrad/src/components/mempool/downloads.rs:215-228` handles three terminal states for a verification task:\n\n- `Ok(Ok(...))`: success. Calls `cancel_handles.remove(\u0026tx.transaction.id)`. Correct.\n- `Ok(Err(...))`: verification error. Calls `cancel_handles.remove(\u0026hash)`. Correct.\n- `Err(elapsed)`: outer timeout. Returns `Err(elapsed)` without removing anything. **Bug.**\n\n`tokio::time::error::Elapsed` has no payload, so the timed-out transaction\u0027s `UnminedTxId` is unrecoverable from the error. The consumer at `zebrad/src/components/mempool.rs:663-672` explicitly acknowledges this gap with a TODO comment.\n\nThe only cleanup paths for `cancel_handles` are `cancel(mined_ids)` (removes entries matching mined transaction IDs; attacker transactions are never mined) and `cancel_all()` (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.\n\nFor direct `tx` pushes (`Gossip::Tx`), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).\n\n### Patches\n\nThe fix preserves the `UnminedTxId` through the timeout error path: wrap the timeout future so the spawned task\u0027s outer error carries the txid (e.g., `Err((txid, elapsed))`). In `Downloads::poll_next()`, on the timeout arm, call `cancel_handles.remove(\u0026txid)`.\n\n### Workarounds\n\nThere is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.\n\n### Impact\n\nGradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.\n\n### Credit\n\nReported by `@AnticsDecoded` via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.",
"id": "GHSA-65jj-fmw8-468q",
"modified": "2026-07-02T20:12:35Z",
"published": "2026-07-02T20:12:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-65jj-fmw8-468q"
},
{
"type": "PACKAGE",
"url": "https://github.com/ZcashFoundation/zebra"
},
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebrad/src/components/mempool.rs#L663-L672"
},
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebrad/src/components/mempool/downloads.rs#L215-L228"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "zebrad has unbounded memory leak in mempool download pipeline via timeout path cancel_handles retention"
}
GHSA-65MJ-5F83-M897
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2024-12-11 15:31In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary variables"), the damon_destroy_ctx() is removed, but still call damon_new_target() and damon_new_region(), the damon_region which is allocated by kmem_cache_alloc() in damon_new_region() and the damon_target which is allocated by kmalloc in damon_new_target() are not freed. And the damon_region which is allocated in damon_new_region() in damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
unreferenced object 0xffff888107c9a940 (size 64):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079cc740 (size 56):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9ac40 (size 64):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079ccc80 (size 56):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffff
---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52560"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()\n\nWhen CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y\nand CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.\n\nSince commit 9f86d624292c (\"mm/damon/vaddr-test: remove unnecessary\nvariables\"), the damon_destroy_ctx() is removed, but still call\ndamon_new_target() and damon_new_region(), the damon_region which is\nallocated by kmem_cache_alloc() in damon_new_region() and the damon_target\nwhich is allocated by kmalloc in damon_new_target() are not freed. And\nthe damon_region which is allocated in damon_new_region() in\ndamon_set_regions() is also not freed.\n\nSo use damon_destroy_target to free all the damon_regions and damon_target.\n\n unreferenced object 0xffff888107c9a940 (size 64):\n comm \"kunit_try_catch\", pid 1069, jiffies 4294670592 (age 732.761s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk\n 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............\n backtrace:\n [\u003cffffffff817e0167\u003e] kmalloc_trace+0x27/0xa0\n [\u003cffffffff819c11cf\u003e] damon_new_target+0x3f/0x1b0\n [\u003cffffffff819c7d55\u003e] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0\n [\u003cffffffff819c82be\u003e] damon_test_apply_three_regions1+0x21e/0x260\n [\u003cffffffff829fce6a\u003e] kunit_generic_run_threadfn_adapter+0x4a/0x90\n [\u003cffffffff81237cf6\u003e] kthread+0x2b6/0x380\n [\u003cffffffff81097add\u003e] ret_from_fork+0x2d/0x70\n [\u003cffffffff81003791\u003e] ret_from_fork_asm+0x11/0x20\n unreferenced object 0xffff8881079cc740 (size 56):\n comm \"kunit_try_catch\", pid 1069, jiffies 4294670592 (age 732.761s)\n hex dump (first 32 bytes):\n 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................\n 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk\n backtrace:\n [\u003cffffffff819bc492\u003e] damon_new_region+0x22/0x1c0\n [\u003cffffffff819c7d91\u003e] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0\n [\u003cffffffff819c82be\u003e] damon_test_apply_three_regions1+0x21e/0x260\n [\u003cffffffff829fce6a\u003e] kunit_generic_run_threadfn_adapter+0x4a/0x90\n [\u003cffffffff81237cf6\u003e] kthread+0x2b6/0x380\n [\u003cffffffff81097add\u003e] ret_from_fork+0x2d/0x70\n [\u003cffffffff81003791\u003e] ret_from_fork_asm+0x11/0x20\n unreferenced object 0xffff888107c9ac40 (size 64):\n comm \"kunit_try_catch\", pid 1071, jiffies 4294670595 (age 732.843s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk\n a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....\n backtrace:\n [\u003cffffffff817e0167\u003e] kmalloc_trace+0x27/0xa0\n [\u003cffffffff819c11cf\u003e] damon_new_target+0x3f/0x1b0\n [\u003cffffffff819c7d55\u003e] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0\n [\u003cffffffff819c851e\u003e] damon_test_apply_three_regions2+0x21e/0x260\n [\u003cffffffff829fce6a\u003e] kunit_generic_run_threadfn_adapter+0x4a/0x90\n [\u003cffffffff81237cf6\u003e] kthread+0x2b6/0x380\n [\u003cffffffff81097add\u003e] ret_from_fork+0x2d/0x70\n [\u003cffffffff81003791\u003e] ret_from_fork_asm+0x11/0x20\n unreferenced object 0xffff8881079ccc80 (size 56):\n comm \"kunit_try_catch\", pid 1071, jiffies 4294670595 (age 732.843s)\n hex dump (first 32 bytes):\n 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................\n 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk\n backtrace:\n [\u003cffffffff819bc492\u003e] damon_new_region+0x22/0x1c0\n [\u003cffffffff819c7d91\u003e] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0\n [\u003cffffffff819c851e\u003e] damon_test_apply_three_regions2+0x21e/0x260\n [\u003cffffffff829fce6a\u003e] kunit_generic_run_threadfn_adapter+0x4a/0x90\n [\u003cffffffff81237cf6\u003e] kthread+0x2b6/0x380\n [\u003cffffffff81097add\u003e] ret_from_fork+0x2d/0x70\n [\u003cffff\n---truncated---",
"id": "GHSA-65mj-5f83-m897",
"modified": "2024-12-11T15:31:14Z",
"published": "2024-03-03T00:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52560"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45120b15743fa7c0aa53d5db6dfb4c8f87be4abd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b522001693aa113d97a985abc5f6932972e8e86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a4fe81a8644b717d57d81ce5849e16583b13fe8"
}
],
"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-65P9-X3QJ-Q764
Vulnerability from github – Published: 2025-05-29 21:31 – Updated: 2025-05-29 21:31A vulnerability, which was classified as problematic, was found in TechPowerUp GPU-Z 2.23.0. Affected is the function sub_140001880 in the library GPU-Z.sys of the component 0x8000645C IOCTL Handler. The manipulation leads to memory leak. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-5324"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-29T19:15:28Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, was found in TechPowerUp GPU-Z 2.23.0. Affected is the function sub_140001880 in the library GPU-Z.sys of the component 0x8000645C IOCTL Handler. The manipulation leads to memory leak. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-65p9-x3qj-q764",
"modified": "2025-05-29T21:31:37Z",
"published": "2025-05-29T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5324"
},
{
"type": "WEB",
"url": "https://github.com/Aiyakami/CVE-1/issues/3"
},
{
"type": "WEB",
"url": "https://github.com/Aiyakami/CVE-1/tree/main/test1"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310494"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310494"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.580513"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-65Q9-FQ96-WQPJ
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-02-27 00:00Moxa TN-5900 v3.1 series routers, MGate 5109 v2.2 series protocol gateways, and MGate 5101-PBM-MN v2.1 series protocol gateways were discovered to contain a memory leak which allows attackers to cause a Denial of Service (DoS) via crafted packets.
{
"affected": [],
"aliases": [
"CVE-2021-46082"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-18T20:15:00Z",
"severity": "HIGH"
},
"details": "Moxa TN-5900 v3.1 series routers, MGate 5109 v2.2 series protocol gateways, and MGate 5101-PBM-MN v2.1 series protocol gateways were discovered to contain a memory leak which allows attackers to cause a Denial of Service (DoS) via crafted packets.",
"id": "GHSA-65q9-fq96-wqpj",
"modified": "2022-02-27T00:00:25Z",
"published": "2022-02-19T00:01:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46082"
},
{
"type": "WEB",
"url": "https://www.moxa.com/en/support/product-support/security-advisory/mgate-5109-5101-protocol-gateways-vulnerability"
},
{
"type": "WEB",
"url": "https://www.moxa.com/en/support/product-support/security-advisory/tn-5900-secure-routers-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-65WQ-6HC9-FGCM
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 21:30In the Linux kernel, the following vulnerability has been resolved:
media: solo6x10: fix possible memory leak in solo_sysfs_init()
If device_register() returns error in solo_sysfs_init(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup().
{
"affected": [],
"aliases": [
"CVE-2022-50547"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: solo6x10: fix possible memory leak in solo_sysfs_init()\n\nIf device_register() returns error in solo_sysfs_init(), the\nname allocated by dev_set_name() need be freed. As comment of\ndevice_register() says, it should use put_device() to give up\nthe reference in the error path. So fix this by calling\nput_device(), then the name can be freed in kobject_cleanup().",
"id": "GHSA-65wq-6hc9-fgcm",
"modified": "2026-02-04T21:30:24Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50547"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49060c0da57a381563e482e331dc9d4c3725b41b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b02c50d3978840781808e13bc13137fb81286b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f5866dd96d95b74e439f6ee17b8abd8195179fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83d4b1ae98a47a739fa5241300b86eb1110d5d63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9416861170ba0da8ddb0f4fd2d28334f0ed3b9c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/963729538674be4cb8fa292529ecf32de0d6c6dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b61509093e1af69e336a094d439b8e1137cb40d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6db105bcfbdbbbd484e788a0ddf8140a4a8c486"
}
],
"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-663M-HM4M-RJG6
Vulnerability from github – Published: 2022-06-15 00:00 – Updated: 2022-06-23 00:00Possible memory leak due to improper validation of certificate chain length while parsing server certificate chain in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2021-35078"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-14T10:15:00Z",
"severity": "HIGH"
},
"details": "Possible memory leak due to improper validation of certificate chain length while parsing server certificate chain in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables",
"id": "GHSA-663m-hm4m-rjg6",
"modified": "2022-06-23T00:00:22Z",
"published": "2022-06-15T00:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35078"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/may-2022-bulletin"
}
],
"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-665R-CJ9V-W263
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-23 21:30In the Linux kernel, the following vulnerability has been resolved:
block: fix zones_cond memory leak on zone revalidation error paths
When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it.
{
"affected": [],
"aliases": [
"CVE-2026-53127"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix zones_cond memory leak on zone revalidation error paths\n\nWhen blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources()\nhas allocated args.zones_cond, the memory is leaked because no error path\nfrees it.",
"id": "GHSA-665r-cj9v-w263",
"modified": "2026-07-23T21:30:35Z",
"published": "2026-06-24T18:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29153d128384fa7c48a8ca8d34094b1cbe2d5bdc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a2f520fda824b5a25c93f2249578ea150c24e06"
}
],
"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.