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-2P5H-C648-WGQH
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_AtomFactory::CreateAtomFromStream function in mp4split.
{
"affected": [],
"aliases": [
"CVE-2022-41426"
],
"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_AtomFactory::CreateAtomFromStream function in mp4split.",
"id": "GHSA-2p5h-c648-wgqh",
"modified": "2022-10-06T00:00:58Z",
"published": "2022-10-04T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41426"
},
{
"type": "WEB",
"url": "https://github.com/axiomatic-systems/Bento4/issues/772"
}
],
"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-2PJ8-R2JF-53PJ
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2024-06-27 15:30In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
{
"affected": [],
"aliases": [
"CVE-2024-26900"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix kmemleak of rdev-\u003eserial\n\nIf kobject_add() is fail in bind_rdev_to_array(), \u0027rdev-\u003eserial\u0027 will be\nalloc not be freed, and kmemleak occurs.\n\nunreferenced object 0xffff88815a350000 (size 49152):\n comm \"mdadm\", pid 789, jiffies 4294716910\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc f773277a):\n [\u003c0000000058b0a453\u003e] kmemleak_alloc+0x61/0xe0\n [\u003c00000000366adf14\u003e] __kmalloc_large_node+0x15e/0x270\n [\u003c000000002e82961b\u003e] __kmalloc_node.cold+0x11/0x7f\n [\u003c00000000f206d60a\u003e] kvmalloc_node+0x74/0x150\n [\u003c0000000034bf3363\u003e] rdev_init_serial+0x67/0x170\n [\u003c0000000010e08fe9\u003e] mddev_create_serial_pool+0x62/0x220\n [\u003c00000000c3837bf0\u003e] bind_rdev_to_array+0x2af/0x630\n [\u003c0000000073c28560\u003e] md_add_new_disk+0x400/0x9f0\n [\u003c00000000770e30ff\u003e] md_ioctl+0x15bf/0x1c10\n [\u003c000000006cfab718\u003e] blkdev_ioctl+0x191/0x3f0\n [\u003c0000000085086a11\u003e] vfs_ioctl+0x22/0x60\n [\u003c0000000018b656fe\u003e] __x64_sys_ioctl+0xba/0xe0\n [\u003c00000000e54e675e\u003e] do_syscall_64+0x71/0x150\n [\u003c000000008b0ad622\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74",
"id": "GHSA-2pj8-r2jf-53pj",
"modified": "2024-06-27T15:30:38Z",
"published": "2024-04-17T12:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26900"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b235bb4c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.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-2PX5-V96W-8G69
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-03 15:30In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memleak due to fentry attach failure
If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms.
This meamleak can be verified by a simple bpf program as follows:
SEC("fentry/trap_init") int fentry_run() { return 0; }
It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms.
$ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]
$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static
$ echo $((6442453466 & 0x7fffffff)) 2522
Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.
{
"affected": [],
"aliases": [
"CVE-2023-53221"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memleak due to fentry attach failure\n\nIf it fails to attach fentry, the allocated bpf trampoline image will be\nleft in the system. That can be verified by checking /proc/kallsyms.\n\nThis meamleak can be verified by a simple bpf program as follows:\n\n SEC(\"fentry/trap_init\")\n int fentry_run()\n {\n return 0;\n }\n\nIt will fail to attach trap_init because this function is freed after\nkernel init, and then we can find the trampoline image is left in the\nsystem by checking /proc/kallsyms.\n\n $ tail /proc/kallsyms\n ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf]\n ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]\n\n $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep \"FUNC \u0027trap_init\u0027\"\n [2522] FUNC \u0027trap_init\u0027 type_id=119 linkage=static\n\n $ echo $((6442453466 \u0026 0x7fffffff))\n 2522\n\nNote that there are two left bpf trampoline images, that is because the\nlibbpf will fallback to raw tracepoint if -EINVAL is returned.",
"id": "GHSA-2px5-v96w-8g69",
"modified": "2025-12-03T15:30:27Z",
"published": "2025-09-15T15:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53221"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/108598c39eefbedc9882273ac0df96127a629220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20109ddd5bea2c24d790debf5d02584ef24c3f5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6aa27775db63ba8c7c73891c7dfb71ddc230c48d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f72c67d1a82dada7d6d504c806e111e913721a30"
}
],
"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-2Q38-88HX-3QF7
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-01 21:30In the Linux kernel, the following vulnerability has been resolved:
recordmcount: Fix memory leaks in the uwrite function
Common realloc mistake: 'file_append' nulled but not freed upon failure
{
"affected": [],
"aliases": [
"CVE-2023-53318"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrecordmcount: Fix memory leaks in the uwrite function\n\nCommon realloc mistake: \u0027file_append\u0027 nulled but not freed upon failure",
"id": "GHSA-2q38-88hx-3qf7",
"modified": "2025-12-01T21:30:23Z",
"published": "2025-09-16T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53318"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25c9b185f121812cbc215fdaa1192c6b9025b428"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ed95a6f6c646e8bb15c354536e0ab10e8f39c08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/444ec005404cead222ebce2561a9451c9ee5ad89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/895130e63c93926f07caf5db286b97bd27b81de9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd39f68a309a947670379bf9a39b16c584f86ddb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff70ad9159fbb566b2c15724f44207e8deccd527"
}
],
"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-2Q39-W2HW-2PJM
Vulnerability from github – Published: 2025-03-28 21:30 – Updated: 2025-03-31 16:10A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.infinispan:infinispan-query"
},
"versions": [
"15.1.0.Dev01"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.infinispan:infinispan-query"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "15.0.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-6875"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-31T16:10:04Z",
"nvd_published_at": "2025-03-28T21:15:17Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API.",
"id": "GHSA-2q39-w2hw-2pjm",
"modified": "2025-03-31T16:10:04Z",
"published": "2025-03-28T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6875"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-6875"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2298555"
},
{
"type": "PACKAGE",
"url": "https://github.com/infinispan/infinispan"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Infinispan Potential Out of Memory Error via REST Compare API Buffer API"
}
GHSA-2Q87-GCQ9-5RFQ
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 21:30In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...
The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path
// error handling path
err_out_mdio_unregister:
mdiobus_unregister(lp->mii_bus);
err_out_mdio:
mdiobus_free(lp->mii_bus); <- the reference count of the first
phy_device is 1, it is not released
and other phy_devices are released
// similarly, the remove process also has the same problem
The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path.
Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully.
{
"affected": [],
"aliases": [
"CVE-2022-50545"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nr6040: Fix kmemleak in probe and remove\n\nThere is a memory leaks reported by kmemleak:\n\n unreferenced object 0xffff888116111000 (size 2048):\n comm \"modprobe\", pid 817, jiffies 4294759745 (age 76.502s)\n hex dump (first 32 bytes):\n 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................\n 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u003cffffffff815bcd82\u003e] kmalloc_trace+0x22/0x60\n [\u003cffffffff827e20ee\u003e] phy_device_create+0x4e/0x90\n [\u003cffffffff827e6072\u003e] get_phy_device+0xd2/0x220\n [\u003cffffffff827e7844\u003e] mdiobus_scan+0xa4/0x2e0\n [\u003cffffffff827e8be2\u003e] __mdiobus_register+0x482/0x8b0\n [\u003cffffffffa01f5d24\u003e] r6040_init_one+0x714/0xd2c [r6040]\n ...\n\nThe problem occurs in probe process as follows:\n r6040_init_one:\n mdiobus_register\n mdiobus_scan \u003c- alloc and register phy_device,\n the reference count of phy_device is 3\n r6040_mii_probe\n phy_connect \u003c- connect to the first phy_device,\n so the reference count of the first\n phy_device is 4, others are 3\n register_netdev \u003c- fault inject succeeded, goto error handling path\n\n // error handling path\n err_out_mdio_unregister:\n mdiobus_unregister(lp-\u003emii_bus);\n err_out_mdio:\n mdiobus_free(lp-\u003emii_bus); \u003c- the reference count of the first\n phy_device is 1, it is not released\n and other phy_devices are released\n // similarly, the remove process also has the same problem\n\nThe root cause is traced to the phy_device is not disconnected when\nremoves one r6040 device in r6040_remove_one() or on error handling path\nafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet\ndevice is connected to the first PHY device of mii_bus, in order to\nnotify the connected driver when the link status changes, which is the\ndefault behavior of the PHY infrastructure to handle everything.\nTherefore the phy_device should be disconnected when removes one r6040\ndevice or on error handling path.\n\nFix it by adding phy_disconnect() when removes one r6040 device or on\nerror handling path after r6040_mii probed successfully.",
"id": "GHSA-2q87-gcq9-5rfq",
"modified": "2026-02-04T21:30:24Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd"
}
],
"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-2QJ8-C2V4-6CG6
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-01 21:31In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw: fix memleak in certain XDP cases
If the XDP program doesn't result in XDP_PASS then we leak the memory allocated by am65_cpsw_build_skb().
It is pointless to allocate SKB memory before running the XDP program as we would be wasting CPU cycles for cases other than XDP_PASS. Move the SKB allocation after evaluating the XDP program result.
This fixes the memleak. A performance boost is seen for XDP_DROP test.
XDP_DROP test: Before: 460256 rx/s 0 err/s After: 784130 rx/s 0 err/s
{
"affected": [],
"aliases": [
"CVE-2025-21788"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix memleak in certain XDP cases\n\nIf the XDP program doesn\u0027t result in XDP_PASS then we leak the\nmemory allocated by am65_cpsw_build_skb().\n\nIt is pointless to allocate SKB memory before running the XDP\nprogram as we would be wasting CPU cycles for cases other than XDP_PASS.\nMove the SKB allocation after evaluating the XDP program result.\n\nThis fixes the memleak. A performance boost is seen for XDP_DROP test.\n\nXDP_DROP test:\nBefore: 460256 rx/s 0 err/s\nAfter: 784130 rx/s 0 err/s",
"id": "GHSA-2qj8-c2v4-6cg6",
"modified": "2025-10-01T21:31:12Z",
"published": "2025-02-27T03:34:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21788"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bba1d042107167164a0ae3a843fdf650ab005d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5db843258de1e4e6b1ef1cbd1797923c9e3de548"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc11f049612b9d926aca2e55f8dc9d82850d0da3"
}
],
"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-2QJP-425J-52J9
Vulnerability from github – Published: 2022-12-07 23:23 – Updated: 2022-12-07 23:23Impact
A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO.
Patches
This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.
For more information
If you have any questions or comments about this advisory:
- Open an issue in containerd
- Email us at security@containerd.io
To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0"
},
{
"fixed": "1.6.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23471"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-07T23:23:43Z",
"nvd_published_at": "2022-12-07T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA bug was found in containerd\u0027s CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user\u0027s process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd\u0027s CRI implementation and the stream server is used for handling container IO.\n\n### Patches\n\nThis bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue.\n\n### Workarounds\n\nEnsure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers. \n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
"id": "GHSA-2qjp-425j-52j9",
"modified": "2022-12-07T23:23:43Z",
"published": "2022-12-07T23:23:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/security/advisories/GHSA-2qjp-425j-52j9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23471"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/commit/241563be06a3de8b6a849414c4e805b68d3bb295"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/commit/a05d175400b1145e5e6a735a6710579d181e7fb0"
},
{
"type": "PACKAGE",
"url": "https://github.com/containerd/containerd"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v1.5.16"
},
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/releases/tag/v1.6.12"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202401-31"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "containerd CRI stream server vulnerable to host memory exhaustion via terminal"
}
GHSA-2QM8-4J25-V4W6
Vulnerability from github – Published: 2024-02-05 18:31 – Updated: 2024-02-08 00:32gpac v2.2.1 was discovered to contain a memory leak via the dst_props variable in the gf_filter_pid_merge_properties_internal function.
{
"affected": [],
"aliases": [
"CVE-2024-24265"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-05T18:15:52Z",
"severity": "HIGH"
},
"details": "gpac v2.2.1 was discovered to contain a memory leak via the dst_props variable in the gf_filter_pid_merge_properties_internal function.",
"id": "GHSA-2qm8-4j25-v4w6",
"modified": "2024-02-08T00:32:19Z",
"published": "2024-02-05T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24265"
},
{
"type": "WEB",
"url": "https://github.com/yinluming13579/gpac_defects/blob/main/gpac_1.md"
}
],
"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-2QM9-92XG-CR8H
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-23 21:30In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.
{
"affected": [],
"aliases": [
"CVE-2023-52754"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imon: fix access to invalid resource for the second interface\n\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver. It\u0027s usually true, but it\u0027s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor. Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0027s a completely different one\nthat was assigned by another driver.\n\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.",
"id": "GHSA-2qm9-92xg-cr8h",
"modified": "2025-09-23T21:30:53Z",
"published": "2024-05-21T18:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e"
}
],
"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.