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-V5FF-5H42-RQ97
Vulnerability from github – Published: 2022-09-15 00:00 – Updated: 2022-09-20 00:00An memory leak issue was discovered in AP4_StdcFileByteStream::Create in mp42ts in Bento4 v1.6.0-639, allows attackers to cause a denial of service via a crafted file.
{
"affected": [],
"aliases": [
"CVE-2022-40439"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-14T21:15:00Z",
"severity": "MODERATE"
},
"details": "An memory leak issue was discovered in AP4_StdcFileByteStream::Create in mp42ts in Bento4 v1.6.0-639, allows attackers to cause a denial of service via a crafted file.",
"id": "GHSA-v5ff-5h42-rq97",
"modified": "2022-09-20T00:00:29Z",
"published": "2022-09-15T00:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40439"
},
{
"type": "WEB",
"url": "https://github.com/axiomatic-systems/Bento4/issues/750"
}
],
"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-V5M7-53CV-F3HX
Vulnerability from github – Published: 2021-08-25 21:01 – Updated: 2022-08-10 23:46Impact
The affected version of this crate's the bounded channel incorrectly assumes that Vec::from_iter has allocated capacity that same as the number of iterator elements. Vec::from_iter does not actually guarantee that and may allocate extra memory. The destructor of the bounded channel reconstructs Vec from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when Vec::from_iter has allocated different sizes with the number of iterator elements.
Patches
This has been fixed in crossbeam-channel 0.4.4.
We recommend users to upgrade to 0.4.4.
References
See https://github.com/crossbeam-rs/crossbeam/pull/533, https://github.com/crossbeam-rs/crossbeam/issues/539, and https://github.com/RustSec/advisory-db/pull/425 for more details.
License
This advisory is in the public domain.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "crossbeam-channel"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.3"
},
{
"fixed": "0.4.4"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.4.3"
]
}
],
"aliases": [
"CVE-2020-15254"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-03T22:53:34Z",
"nvd_published_at": "2020-10-16T17:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThe affected version of this crate\u0027s the `bounded` channel incorrectly assumes that `Vec::from_iter` has allocated capacity that same as the number of iterator elements. `Vec::from_iter` does not actually guarantee that and may allocate extra memory. The destructor of the `bounded` channel reconstructs `Vec` from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when `Vec::from_iter` has allocated different sizes with the number of iterator elements.\n\n### Patches\n\nThis has been fixed in crossbeam-channel 0.4.4.\n\nWe recommend users to upgrade to 0.4.4.\n\n### References\n\nSee https://github.com/crossbeam-rs/crossbeam/pull/533, https://github.com/crossbeam-rs/crossbeam/issues/539, and https://github.com/RustSec/advisory-db/pull/425 for more details.\n\n### License\n\nThis advisory is in the public domain.",
"id": "GHSA-v5m7-53cv-f3hx",
"modified": "2022-08-10T23:46:00Z",
"published": "2021-08-25T21:01:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/crossbeam-rs/crossbeam/security/advisories/GHSA-v5m7-53cv-f3hx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15254"
},
{
"type": "WEB",
"url": "https://github.com/crossbeam-rs/crossbeam/issues/539"
},
{
"type": "WEB",
"url": "https://github.com/RustSec/advisory-db/pull/425"
},
{
"type": "WEB",
"url": "https://github.com/crossbeam-rs/crossbeam/pull/533"
},
{
"type": "PACKAGE",
"url": "https://github.com/crossbeam-rs/crossbeam"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0052.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "crossbeam-channel Undefined Behavior before v0.4.4"
}
GHSA-V645-356V-8X2F
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 21:31In the Linux kernel, the following vulnerability has been resolved:
USB: fotg210: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
{
"affected": [],
"aliases": [
"CVE-2023-53404"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: fotg210: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.",
"id": "GHSA-v645-356v-8x2f",
"modified": "2025-12-12T21:31:31Z",
"published": "2025-09-18T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53404"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a71b15744b8f286718722f80b663c06ed909d8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55c2ffc534928f4732199617e3b746d79a57898f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b4040f452037a7e95472577891d57c6b18c89c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d2d3bef6d700eb4261fb6761de2c95a9e3c0ac8"
}
],
"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-V687-G54P-GVWJ
Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2022-05-24 17:12An exploitable denial-of-service vulnerability exists in the resource allocation handling of Videolabs libmicrodns 0.1.0. When encountering errors while parsing mDNS messages, some allocated data is not freed, possibly leading to a denial-of-service condition via resource exhaustion. An attacker can send one mDNS message repeatedly to trigger this vulnerability through the function rr_read_RR [5] reads the current resource record, except for the RDATA section. This is read by the loop at in rr_read. For each RR type, a different function is called. When the RR type is 0x10, the function rr_read_TXT is called at [6].
{
"affected": [],
"aliases": [
"CVE-2020-6080"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-24T21:15:00Z",
"severity": "MODERATE"
},
"details": "An exploitable denial-of-service vulnerability exists in the resource allocation handling of Videolabs libmicrodns 0.1.0. When encountering errors while parsing mDNS messages, some allocated data is not freed, possibly leading to a denial-of-service condition via resource exhaustion. An attacker can send one mDNS message repeatedly to trigger this vulnerability through the function rr_read_RR [5] reads the current resource record, except for the RDATA section. This is read by the loop at in rr_read. For each RR type, a different function is called. When the RR type is 0x10, the function rr_read_TXT is called at [6].",
"id": "GHSA-v687-g54p-gvwj",
"modified": "2022-05-24T17:12:35Z",
"published": "2022-05-24T17:12:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6080"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202005-10"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1002"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4671"
}
],
"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-V68J-GHQ9-FFVC
Vulnerability from github – Published: 2024-04-17 18:31 – Updated: 2024-04-29 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix several DMA buffer leaks
Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads.
Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate.
Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects.
{
"affected": [],
"aliases": [
"CVE-2024-26912"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T16:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix several DMA buffer leaks\n\nNouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of\nthese buffers are never dealloced. Some of them can be deallocated\nright after GSP-RM is initialized, but the rest need to stay until the\ndriver unloads.\n\nAlso futher bullet-proof these objects by poisoning the buffer and\nclearing the nvkm_gsp_mem object when it is deallocated. Poisoning\nthe buffer should trigger an error (or crash) from GSP-RM if it tries\nto access the buffer after we\u0027ve deallocated it, because we were wrong\nabout when it is safe to deallocate.\n\nFinally, change the mem-\u003esize field to a size_t because that\u0027s the same\ntype that dma_alloc_coherent expects.",
"id": "GHSA-v68j-ghq9-ffvc",
"modified": "2024-04-29T21:30:34Z",
"published": "2024-04-17T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26912"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/042b5f83841fbf7ce39474412db3b5e4765a7ea7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6190d4c08897d748dd25f0b78267a90aa1694e15"
}
],
"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-V6F8-XXJ7-93G3
Vulnerability from github – Published: 2022-01-20 00:01 – Updated: 2022-02-02 00:02A Missing Release of Memory after Effective Lifetime vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a memory leak. Continued exploitation can lead to memory exhaustion and thereby a Denial of Service (DoS). This issue occurs when specific LLDP packets are received. The impact of the l2cpd cores is that if any of the stp protocols (rstp, mstp or vstp) is used then stp re-converges and traffic loss will occur during that time. Also if any services depend on LLDP state (like PoE or VoIP device recognition) then these will also be affected. The memory utilization of the L2CPd process can be monitored with the following command: user@host> show system processes extensive | match l2cpd 1234 root 52 0 521M 43412K RUN 1 4:02 34.47% l2cpd This issue affects: Juniper Networks Junos OS 18.4 version 18.4R2-S4 and later versions prior to 18.4R2-S10. 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R2; Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S2-EVO; 21.1 version 21.1R1-EVO and later versions; 21.2 versions prior to 21.2R2-EVO. This issue does not affect: Juniper Networks Junos OS 19.1 version 19.1R1 and later versions.
{
"affected": [],
"aliases": [
"CVE-2022-22172"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-19T01:15:00Z",
"severity": "MODERATE"
},
"details": "A Missing Release of Memory after Effective Lifetime vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a memory leak. Continued exploitation can lead to memory exhaustion and thereby a Denial of Service (DoS). This issue occurs when specific LLDP packets are received. The impact of the l2cpd cores is that if any of the stp protocols (rstp, mstp or vstp) is used then stp re-converges and traffic loss will occur during that time. Also if any services depend on LLDP state (like PoE or VoIP device recognition) then these will also be affected. The memory utilization of the L2CPd process can be monitored with the following command: user@host\u003e show system processes extensive | match l2cpd 1234 root 52 0 521M 43412K RUN 1 4:02 34.47% l2cpd This issue affects: Juniper Networks Junos OS 18.4 version 18.4R2-S4 and later versions prior to 18.4R2-S10. 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R2; Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S2-EVO; 21.1 version 21.1R1-EVO and later versions; 21.2 versions prior to 21.2R2-EVO. This issue does not affect: Juniper Networks Junos OS 19.1 version 19.1R1 and later versions.",
"id": "GHSA-v6f8-xxj7-93g3",
"modified": "2022-02-02T00:02:21Z",
"published": "2022-01-20T00:01:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22172"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11278"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V6JM-7R7P-9979
Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task / rpc_task1 / rpc_run_task rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop ... nfs4_run_open_task / rpc_task2 / rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dum ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-56779"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T18:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n NFS CLIENT\nthread1 thread2\nopen(\"file\")\n...\nnfs4_do_open\n _nfs4_do_open\n _nfs4_open_and_get_state\n _nfs4_proc_open\n nfs4_run_open_task\n /* rpc_task1 */\n rpc_run_task\n rpc_wait_for_completion_task\n\n umount -f\n nfs_umount_begin\n rpc_killall_tasks\n rpc_signal_task\n rpc_task1 been wakeup\n and return -512\n _nfs4_do_open // while loop\n ...\n nfs4_run_open_task\n /* rpc_task2 */\n rpc_run_task\n rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n NFS SERVER\nnfsd1 nfsd2 echo 0 \u003e /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // alloc oo1, stateid1\n nfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // find oo1, without NFS4_OO_CONFIRMED\n release_openowner\n unhash_openowner_locked\n list_del_init(\u0026oo-\u003eoo_perclient)\n // cannot find this oo\n // from client, LEAK!!!\n alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n init_open_stateid\n // associate oo1\n // with stateid1, stateid1 LEAK!!!\n nfs4_get_vfs_file\n // alloc nfsd_file1 and nfsd_file_mark1\n // all LEAK!!!\n\n nfsd4_process_open2\n ...\n\n write_threads\n ...\n nfsd_destroy_serv\n nfsd_shutdown_net\n nfs4_state_shutdown_net\n nfs4_state_destroy_net\n destroy_client\n __destroy_client\n // won\u0027t find oo1!!!\n nfsd_shutdown_generic\n nfsd_file_cache_shutdown\n kmem_cache_destroy\n for nfsd_file_slab\n and nfsd_file_mark_slab\n // bark since nfsd_file1\n // and nfsd_file_mark1\n // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dum\n---truncated---",
"id": "GHSA-v6jm-7r7p-9979",
"modified": "2025-11-03T21:32:05Z",
"published": "2025-01-08T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ab0a3ad24e970e894abcac58f85c332d1726749"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d505a801e57428057563762f67a5a62009b2600"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37dfc81266d3a32294524bfadd3396614f8633ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45abb68c941ebc9a35c6d3a7b08196712093c636"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f73f920b7ad0084373e46121d7ac34117aed652"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98100e88dd8865999dc6379a3356cd799795fe7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a85364f0d30dee01c5d5b4afa55a9629a8f36d8e"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/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-V6QQ-2P53-438J
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
virt: tdx-guest: Just leak decrypted memory on unrecoverable errors
In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE().
{
"affected": [],
"aliases": [
"CVE-2024-57793"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirt: tdx-guest: Just leak decrypted memory on unrecoverable errors\n\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_decrypted() to fail such that an error is returned\nand the resulting memory is shared. Callers need to take care\nto handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional\nor security issues.\n\nLeak the decrypted memory when set_memory_decrypted() fails,\nand don\u0027t need to print an error since set_memory_decrypted()\nwill call WARN_ONCE().",
"id": "GHSA-v6qq-2p53-438j",
"modified": "2025-09-24T21:30:31Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1429ae7b7d4759a1e362456b8911c701bae655b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27834971f616c5e154423c578fa95e0444444ce1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V76P-9FF9-F29G
Vulnerability from github – Published: 2025-04-17 21:30 – Updated: 2025-04-17 21:30In the Linux kernel, the following vulnerability has been resolved:
lib/string_helpers: fix not adding strarray to device's resource list
Add allocated strarray to device's resource list. This is a must to automatically release strarray when the device disappears.
Without this fix we have a memory leak in the few drivers which use devm_kasprintf_strarray().
{
"affected": [],
"aliases": [
"CVE-2022-49403"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/string_helpers: fix not adding strarray to device\u0027s resource list\n\nAdd allocated strarray to device\u0027s resource list. This is a must to\nautomatically release strarray when the device disappears.\n\nWithout this fix we have a memory leak in the few drivers which use\ndevm_kasprintf_strarray().",
"id": "GHSA-v76p-9ff9-f29g",
"modified": "2025-04-17T21:30:44Z",
"published": "2025-04-17T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49403"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a152eb42fcecfe41239c3c6695342f3a128593e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf29edab0c9ff3d2633b8306a67d04c357e2a385"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd290a9839cee2f6641558877e707bd373c8f6f1"
}
],
"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-V799-GFW3-G83C
Vulnerability from github – Published: 2026-07-15 12:32 – Updated: 2026-07-15 12:32ImageMagick before 7.1.2-26 (and 6.x before 6.9.13-51) contains a memory leak in the TIFF encoder that occurs when a temporary file cannot be created, resulting in a small memory leak.
{
"affected": [],
"aliases": [
"CVE-2026-61863"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-15T12:18:21Z",
"severity": "LOW"
},
"details": "ImageMagick before 7.1.2-26 (and 6.x before 6.9.13-51) contains a memory leak in the TIFF encoder that occurs when a temporary file cannot be created, resulting in a small memory leak.",
"id": "GHSA-v799-gfw3-g83c",
"modified": "2026-07-15T12:32:05Z",
"published": "2026-07-15T12:32:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-6vxp-gfwf-hcr9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61863"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/imagemagick-before-26-memory-leak-in-tiff-encoder"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/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"
}
]
}
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.