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.
2002 vulnerabilities reference this CWE, most recent first.
GHSA-6432-66V6-M255
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix memory leak in amdxdna_ubuf_map
The amdxdna_ubuf_map() function allocates memory for sg and internal sg table structures, but it fails to free them if subsequent operations (sg_alloc_table_from_pages or dma_map_sgtable) fail.
{
"affected": [],
"aliases": [
"CVE-2026-45908"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix memory leak in amdxdna_ubuf_map\n\nThe amdxdna_ubuf_map() function allocates memory for sg and\ninternal sg table structures, but it fails to free them if subsequent\noperations (sg_alloc_table_from_pages or dma_map_sgtable) fail.",
"id": "GHSA-6432-66v6-m255",
"modified": "2026-06-24T18:32:27Z",
"published": "2026-05-27T15:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45908"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a68d2c99c859e6e8e36fa4e32749abf6d1fb66a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84dd57fb0359500092f1101409ca32091731490d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9f4366d2ff93b07c2571561c776bd9a708078c3"
}
],
"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-64FJ-7445-HXWQ
Vulnerability from github – Published: 2022-10-04 00:00 – Updated: 2022-10-06 00:00Bento4 v1.6.0-639 was discovered to contain a memory leak via the AP4_SttsAtom::Create function in mp42hls.
{
"affected": [],
"aliases": [
"CVE-2022-41424"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-03T14:15:00Z",
"severity": "MODERATE"
},
"details": "Bento4 v1.6.0-639 was discovered to contain a memory leak via the AP4_SttsAtom::Create function in mp42hls.",
"id": "GHSA-64fj-7445-hxwq",
"modified": "2022-10-06T00:00:58Z",
"published": "2022-10-04T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41424"
},
{
"type": "WEB",
"url": "https://github.com/axiomatic-systems/Bento4/issues/768"
}
],
"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-64QM-44W9-R4FM
Vulnerability from github – Published: 2024-03-01 00:30 – Updated: 2024-12-10 18:31In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ss - fix result memory leak on error path
This patch fixes a memory leak on an error path.
{
"affected": [],
"aliases": [
"CVE-2021-47059"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T23:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: sun8i-ss - fix result memory leak on error path\n\nThis patch fixes a memory leak on an error path.",
"id": "GHSA-64qm-44w9-r4fm",
"modified": "2024-12-10T18:31:06Z",
"published": "2024-03-01T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47059"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dbc6a1e25be8575d6c4114d1d2b841a796507f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f12aaf07f61122cf5074d29714ee26f8d44b0e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50e7b39b808430ad49a637dc6fb72ca93b451b13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca065a93699f8cf3f42c60eefed73086007e928e"
}
],
"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-64V3-VWP6-Q2HJ
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-23 21:30In the Linux kernel, the following vulnerability has been resolved:
mmc: sdio: fix possible resource leaks in some error paths
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device().
To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device().
In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced.
Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone.
unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
{
"affected": [],
"aliases": [
"CVE-2023-52730"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdio: fix possible resource leaks in some error paths\n\nIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can\nnot release the resources, because the sdio function is not presented\nin these two cases, it won\u0027t call of_node_put() or put_device().\n\nTo fix these leaks, make sdio_func_present() only control whether\ndevice_del() needs to be called or not, then always call of_node_put()\nand put_device().\n\nIn error case in sdio_init_func(), the reference of \u0027card-\u003edev\u0027 is\nnot get, to avoid redundant put in sdio_free_func_cis(), move the\nget_device() to sdio_alloc_func() and put_device() to sdio_release_func(),\nit can keep the get/put function be balanced.\n\nWithout this patch, while doing fault inject test, it can get the\nfollowing leak reports, after this fix, the leak is gone.\n\nunreferenced object 0xffff888112514000 (size 2048):\n comm \"kworker/3:2\", pid 65, jiffies 4294741614 (age 124.774s)\n hex dump (first 32 bytes):\n 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......\n 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....\n backtrace:\n [\u003c000000009e5931da\u003e] kmalloc_trace+0x21/0x110\n [\u003c000000002f839ccb\u003e] mmc_alloc_card+0x38/0xb0 [mmc_core]\n [\u003c0000000004adcbf6\u003e] mmc_sdio_init_card+0xde/0x170 [mmc_core]\n [\u003c000000007538fea0\u003e] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]\n [\u003c00000000d4fdeba7\u003e] mmc_rescan+0x54a/0x640 [mmc_core]\n\nunreferenced object 0xffff888112511000 (size 2048):\n comm \"kworker/3:2\", pid 65, jiffies 4294741623 (age 124.766s)\n hex dump (first 32 bytes):\n 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......\n 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....\n backtrace:\n [\u003c000000009e5931da\u003e] kmalloc_trace+0x21/0x110\n [\u003c00000000fcbe706c\u003e] sdio_alloc_func+0x35/0x100 [mmc_core]\n [\u003c00000000c68f4b50\u003e] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]\n [\u003c00000000d4fdeba7\u003e] mmc_rescan+0x54a/0x640 [mmc_core]",
"id": "GHSA-64v3-vwp6-q2hj",
"modified": "2025-09-23T21:30:53Z",
"published": "2024-05-21T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52730"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280f308ded"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72"
}
],
"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-64VG-6M9Q-6VR3
Vulnerability from github – Published: 2025-08-19 21:30 – Updated: 2025-08-26 18:31A flaw has been found in LibTIFF 4.7.0. This affects the function _TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing manipulation can lead to memory leak. The attack is restricted to local execution. The exploit has been published and may be used. This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is best practice to apply a patch to resolve this issue.
{
"affected": [],
"aliases": [
"CVE-2025-9165"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T20:15:37Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in LibTIFF 4.7.0. This affects the function _TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing manipulation can lead to memory leak. The attack is restricted to local execution. The exploit has been published and may be used. This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is best practice to apply a patch to resolve this issue.",
"id": "GHSA-64vg-6m9q-6vr3",
"modified": "2025-08-26T18:31:14Z",
"published": "2025-08-19T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9165"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1FWhmkzksH8-qU0ZM6seBzGNB3aPnX3G8/view?usp=sharing"
},
{
"type": "WEB",
"url": "https://gitlab.com/libtiff/libtiff/-/commit/ed141286a37f6e5ddafb5069347ff5d587e7a4e0"
},
{
"type": "WEB",
"url": "https://gitlab.com/libtiff/libtiff/-/issues/728"
},
{
"type": "WEB",
"url": "https://gitlab.com/libtiff/libtiff/-/issues/728#note_2709263214"
},
{
"type": "WEB",
"url": "https://gitlab.com/libtiff/libtiff/-/merge_requests/747"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.320543"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.320543"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.630506"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.630507"
},
{
"type": "WEB",
"url": "http://www.libtiff.org"
}
],
"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:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/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-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"
}
]
}
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.