Common Weakness Enumeration
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.
2010 vulnerabilities reference this CWE, most recent first.
GHSA-GHFF-7R8P-2PR4
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2024-11-13 18:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()
modprobe iio-test-gts and rmmod it, then the following memory leak occurs:
unreferenced object 0xffffff80c810be00 (size 64):
comm "kunit_try_catch", pid 1654, jiffies 4294913981
hex dump (first 32 bytes):
02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@...
80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................
backtrace (crc a63d875e):
[<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
[<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
[<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
[<0000000071bb4b09>] 0xffffffdf052a62e0
[<000000000315bc18>] 0xffffffdf052a6488
[<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
[<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000f505065d>] kthread+0x2e8/0x374
[<00000000bbfb0e5d>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cbfe9e70 (size 16):
comm "kunit_try_catch", pid 1658, jiffies 4294914015
hex dump (first 16 bytes):
10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@...........
backtrace (crc 857f0cb4):
[<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
[<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
[<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
[<0000000071bb4b09>] 0xffffffdf052a62e0
[<000000007d089d45>] 0xffffffdf052a6864
[<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
[<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000f505065d>] kthread+0x2e8/0x374
[<00000000bbfb0e5d>] ret_from_fork+0x10/0x20
......
It includes 55 times "size 64" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10size(int)) and gts_test_itimes size 5. It also includes 51 times "size 16" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3size(int)) and gts_test_itimes size 5.
The reason is that the per_time_gains[i] is not freed which is allocated in the "gts->num_itime" for loop in iio_gts_build_avail_scale_table().
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-50231"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()\n\nmodprobe iio-test-gts and rmmod it, then the following memory leak\noccurs:\n\n\tunreferenced object 0xffffff80c810be00 (size 64):\n\t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981\n\t hex dump (first 32 bytes):\n\t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@...\n\t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................\n\t backtrace (crc a63d875e):\n\t [\u003c0000000028c1b3c2\u003e] kmemleak_alloc+0x34/0x40\n\t [\u003c000000001d6ecc87\u003e] __kmalloc_noprof+0x2bc/0x3c0\n\t [\u003c00000000393795c1\u003e] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t [\u003c0000000071bb4b09\u003e] 0xffffffdf052a62e0\n\t [\u003c000000000315bc18\u003e] 0xffffffdf052a6488\n\t [\u003c00000000f9dc55b5\u003e] kunit_try_run_case+0x13c/0x3ac\n\t [\u003c00000000175a3fd4\u003e] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t [\u003c00000000f505065d\u003e] kthread+0x2e8/0x374\n\t [\u003c00000000bbfb0e5d\u003e] ret_from_fork+0x10/0x20\n\tunreferenced object 0xffffff80cbfe9e70 (size 16):\n\t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015\n\t hex dump (first 16 bytes):\n\t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@...........\n\t backtrace (crc 857f0cb4):\n\t [\u003c0000000028c1b3c2\u003e] kmemleak_alloc+0x34/0x40\n\t [\u003c000000001d6ecc87\u003e] __kmalloc_noprof+0x2bc/0x3c0\n\t [\u003c00000000393795c1\u003e] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t [\u003c0000000071bb4b09\u003e] 0xffffffdf052a62e0\n\t [\u003c000000007d089d45\u003e] 0xffffffdf052a6864\n\t [\u003c00000000f9dc55b5\u003e] kunit_try_run_case+0x13c/0x3ac\n\t [\u003c00000000175a3fd4\u003e] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t [\u003c00000000f505065d\u003e] kthread+0x2e8/0x374\n\t [\u003c00000000bbfb0e5d\u003e] ret_from_fork+0x10/0x20\n\t......\n\nIt includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times\ntest_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))\nand gts_test_itimes size 5. It also includes 5*1 times \"size 16\"\nmemory leak, which correspond to one time __test_init_iio_gain_scale()\ncall with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes\nsize 5.\n\nThe reason is that the per_time_gains[i] is not freed which is allocated in\nthe \"gts-\u003enum_itime\" for loop in iio_gts_build_avail_scale_table().",
"id": "GHSA-ghff-7r8p-2pr4",
"modified": "2024-11-13T18:31:53Z",
"published": "2024-11-09T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50231"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16e41593825c3044efca0eb34b2d6ffba306e4ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38d6e8be234d87b0eedca50309e25051888b39d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/691e79ffc42154a9c91dc3b7e96a307037b4be74"
}
],
"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-GHM8-6M3X-WV66
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-11-07 19:00
VLAI
Details
A memory leak in the rpmsg_eptdev_write_iter() function in drivers/rpmsg/rpmsg_char.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering copy_from_iter_full() failures, aka CID-bbe692e349e2.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2019-19053"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-18T06:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak in the rpmsg_eptdev_write_iter() function in drivers/rpmsg/rpmsg_char.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering copy_from_iter_full() failures, aka CID-bbe692e349e2.",
"id": "GHSA-ghm8-6m3x-wv66",
"modified": "2022-11-07T19:00:18Z",
"published": "2022-05-24T17:01:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19053"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/bbe692e349e2a1edf3fe0a29a0e05899c9c94d51"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4300-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4301-1"
}
],
"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-GHPP-GWGC-8PQ9
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: restore failed global reservations to subpool
Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation.
Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.
Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit.
The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.
With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.
Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.
The underflow issue that the original commit fixes still remains fixed as well.
Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-43286"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: restore failed global reservations to subpool\n\nCommit a833a693a490 (\"mm: hugetlb: fix incorrect fallback for subpool\")\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\nattributing globally requested pages to the subpool\u0027s reservation.\n\nUnfortunately, this fix also introduced the opposite problem, which would\nleave spool-\u003eused_hpages elevated if the globally requested pages could\nnot be acquired. This is because while a subpool\u0027s reserve pages only\naccounts for what is requested and allocated from the subpool, its \"used\"\ncounter keeps track of what is consumed in total, both from the subpool\nand globally. Thus, we need to adjust spool-\u003eused_hpages in the other\ndirection, and make sure that globally requested pages are uncharged from\nthe subpool\u0027s used counter.\n\nEach failed allocation attempt increments the used_hpages counter by how\nmany pages were requested from the global pool. Ultimately, this renders\nthe subpool unusable, as used_hpages approaches the max limit.\n\nThe issue can be reproduced as follows:\n1. Allocate 4 hugetlb pages\n2. Create a hugetlb mount with max=4, min=2\n3. Consume 2 pages globally\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\n\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\n\t\tused_hpages += 3\n\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\n\t\tused_hpages -= 2\n5. Subpool now has used_hpages = 1, despite not being able to\n successfully allocate any hugepages. It believes it can now only\n allocate 3 more hugepages, not 4.\n\nWith each failed allocation attempt incrementing the used counter, the\nsubpool eventually reaches a point where its used counter equals its\nmax counter. At that point, any future allocations that try to\nallocate hugeTLB pages from the subpool will fail, despite the subpool\nnot having any of its hugeTLB pages consumed by any user.\n\nOnce this happens, there is no way to make the subpool usable again,\nsince there is no way to decrement the used counter as no process is\nreally consuming the hugeTLB pages.\n\nThe underflow issue that the original commit fixes still remains fixed\nas well.\n\nWithout this fix, used_hpages would keep on leaking if\nhugetlb_acct_memory() fails.",
"id": "GHSA-ghpp-gwgc-8pq9",
"modified": "2026-05-15T18:30:29Z",
"published": "2026-05-08T15:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43286"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5"
}
],
"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-GHW9-6H55-QJ7V
Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2025-11-04 00:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.
This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.
Severity
4.7 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-42152"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\n\nIn nvmet_sq_destroy we capture sq-\u003ectrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u003esqs and sq-\u003ectrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\n\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u003eref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u003ectrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\n\nSolve this by re-capturing the sq-\u003ectrl after all inflight request has\ncompleted, where for sure sq-\u003ectrl reference is final, and move forward\nbased on that.\n\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.",
"id": "GHSA-ghw9-6h55-qj7v",
"modified": "2025-11-04T00:31:08Z",
"published": "2024-07-30T09:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GJ59-54PG-84P6
Vulnerability from github – Published: 2025-10-15 15:30 – Updated: 2025-10-15 15:30
VLAI
Details
When SNMP is configured on F5OS Appliance and Chassis systems, undisclosed requests can cause an increase in SNMP memory resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
Severity
{
"affected": [],
"aliases": [
"CVE-2025-47150"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T14:15:47Z",
"severity": "HIGH"
},
"details": "When SNMP is configured on F5OS Appliance and Chassis systems, undisclosed requests can cause an increase in SNMP memory resource utilization.\u00a0 Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-gj59-54pg-84p6",
"modified": "2025-10-15T15:30:28Z",
"published": "2025-10-15T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47150"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000149820"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/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-GJH2-VJQ2-JQWC
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2022-49923"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nxp-nci: Fix potential memory leak in nxp_nci_send()\n\nnxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when\nnxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()\nrun succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the\nresult, the skb will memleak. nxp_nci_send() should also free the skb\nwhen nxp_nci_i2c_write() succeeds.",
"id": "GHSA-gjh2-vjq2-jqwc",
"modified": "2025-05-07T15:31:27Z",
"published": "2025-05-01T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49923"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cba1f061bfe23fece2841129ca2862cdec29d5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ecf0f4227029b2c42e036b10ff6e5d09e20821e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bf1ed6aff0f70434bd0cdd45495e83f1dffb551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ae2c9a91ff068f4c3e392f47e8e26a1c9f85ebb"
}
],
"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-GJPW-73P9-V6CG
Vulnerability from github – Published: 2025-09-23 18:30 – Updated: 2025-09-23 18:30
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
drm/imx: Fix memory leak in imx_pd_connector_get_modes
Avoid leaking the display mode variable if of_get_drm_display_mode fails.
Addresses-Coverity-ID: 1443943 ("Resource leak")
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2022-49091"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imx: Fix memory leak in imx_pd_connector_get_modes\n\nAvoid leaking the display mode variable if of_get_drm_display_mode\nfails.\n\nAddresses-Coverity-ID: 1443943 (\"Resource leak\")",
"id": "GHSA-gjpw-73p9-v6cg",
"modified": "2025-09-23T18:30:20Z",
"published": "2025-09-23T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49091"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31e449302ed00c38d4068443cf0243279701ab28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7526102d908ec5ae777aa77723d52fce12916093"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc23c327e1a23cc3555fa1e86288e13288515442"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e46996d013f3d5967"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2c2758cfb0262637fd93350bdc8ad485fb1dd61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8b0ef0a5889890b50482b6593bd8de544736351"
}
],
"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-GJPW-FMCG-X3XF
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 21:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: gr_udc: 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.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-53405"
],
"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: gadget: gr_udc: 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-gjpw-fmcg-x3xf",
"modified": "2025-12-12T21:31:31Z",
"published": "2025-09-18T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53405"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0933eca15f5223b5c2412080c8c3de8758465c78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30f9ba2396a1130eef7f2d3ee7ee8037b7c25be9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73f4451368663ad28daa67980c6dd11d83b303eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be21a66e17ee0ab5f3513b6c86659e60cec5e981"
}
],
"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-GJXW-MRG7-952F
Vulnerability from github – Published: 2026-01-27 18:32 – Updated: 2026-01-28 18:30
VLAI
Details
Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-28164"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-27T16:16:14Z",
"severity": "MODERATE"
},
"details": "Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.",
"id": "GHSA-gjxw-mrg7-952f",
"modified": "2026-01-28T18:30:47Z",
"published": "2026-01-27T18:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28164"
},
{
"type": "WEB",
"url": "https://github.com/pnggroup/libpng/issues/655"
},
{
"type": "WEB",
"url": "https://gist.github.com/kittener/506516f8c22178005b4379c8b2a7de20"
}
],
"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-GM37-QX7W-P258
Vulnerability from github – Published: 2026-02-24 15:30 – Updated: 2026-02-24 15:30
VLAI
Summary
ImageMagick: Possible memory leak in ASHLAR encoder
Details
A memory leak in the ASHLAR image writer allows an attacker to exhaust process memory by providing a crafted image that results in small objects that are allocated but never freed.
==880062== Memcheck, a memory error detector
==880062== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==880062== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==880062==
==880062==
==880062== HEAP SUMMARY:
==880062== in use at exit: 386,826 bytes in 696 blocks
==880062== total heap usage: 30,523 allocs, 29,827 frees, 21,803,756 bytes allocated
==880062==
==880062== LEAK SUMMARY:
==880062== definitely lost: 3,408 bytes in 3 blocks
==880062== indirectly lost: 88,885 bytes in 30 blocks
==880062== possibly lost: 140,944 bytes in 383 blocks
==880062== still reachable: 151,573 bytes in 259 blocks
==880062== suppressed: 0 bytes in 0 blocks
==880062== Reachable blocks (those to which a pointer was found) are not shown.
==880062== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==880062==
==880062== For lists of detected and suppressed errors, rerun with: -s
==880062== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25637"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-24T15:30:16Z",
"nvd_published_at": "2026-02-24T01:16:13Z",
"severity": "MODERATE"
},
"details": "A memory leak in the ASHLAR image writer allows an attacker to exhaust process memory by providing a crafted image that results in small objects that are allocated but never freed.\n\n```\n==880062== Memcheck, a memory error detector\n==880062== Copyright (C) 2002-2017, and GNU GPL\u0027d, by Julian Seward et al.\n==880062== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info\n==880062== \n==880062== \n==880062== HEAP SUMMARY:\n==880062== in use at exit: 386,826 bytes in 696 blocks\n==880062== total heap usage: 30,523 allocs, 29,827 frees, 21,803,756 bytes allocated\n==880062== \n==880062== LEAK SUMMARY:\n==880062== definitely lost: 3,408 bytes in 3 blocks\n==880062== indirectly lost: 88,885 bytes in 30 blocks\n==880062== possibly lost: 140,944 bytes in 383 blocks\n==880062== still reachable: 151,573 bytes in 259 blocks\n==880062== suppressed: 0 bytes in 0 blocks\n==880062== Reachable blocks (those to which a pointer was found) are not shown.\n==880062== To see them, rerun with: --leak-check=full --show-leak-kinds=all\n==880062== \n==880062== For lists of detected and suppressed errors, rerun with: -s\n==880062== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)\n```",
"id": "GHSA-gm37-qx7w-p258",
"modified": "2026-02-24T15:30:16Z",
"published": "2026-02-24T15:30:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-gm37-qx7w-p258"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25637"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/30ce0e8efbd72fd6b50ed3a10ae22f57c8901137"
},
{
"type": "PACKAGE",
"url": "https://github.com/ImageMagick/ImageMagick"
},
{
"type": "WEB",
"url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.10.3"
}
],
"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": "ImageMagick: Possible memory leak in ASHLAR encoder"
}
Mitigation MIT-41
Implementation
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
Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation
Architecture and Design
Build and Compilation
Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
No CAPEC attack patterns related to this CWE.