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.
2014 vulnerabilities reference this CWE, most recent first.
GHSA-JXX5-V8QW-45P6
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix reset_method_store() memory leak
In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces:
while ((name = strsep(&options, " ")) != NULL) {
If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup().
Fix by using a separate tmp_options to iterate with strsep() so options is preserved.
{
"affected": [],
"aliases": [
"CVE-2024-56745"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix reset_method_store() memory leak\n\nIn reset_method_store(), a string is allocated via kstrndup() and assigned\nto the local \"options\". options is then used in with strsep() to find\nspaces:\n\n while ((name = strsep(\u0026options, \" \")) != NULL) {\n\nIf there are no remaining spaces, then options is set to NULL by strsep(),\nso the subsequent kfree(options) doesn\u0027t free the memory allocated via\nkstrndup().\n\nFix by using a separate tmp_options to iterate with strsep() so options is\npreserved.",
"id": "GHSA-jxx5-v8qw-45p6",
"modified": "2025-11-03T21:32:02Z",
"published": "2024-12-29T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56745"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2985b1844f3f3447f2d938eff1ef6762592065a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/403efb4457c0c8f8f51e904cc57d39193780c6bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/543d0eb40e45c6a51f1bff02f417b602e54472d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e098baf6bc3f3a6aefc383509aba07e202f7ee0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/931d07ccffcc3614f20aaf602b31e89754e21c59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe6fae61f3b993160aef5fe2b7141a83872c144f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.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-M237-4JXG-W5JH
Vulnerability from github – Published: 2026-06-24 09:30 – Updated: 2026-06-30 03:37In the Linux kernel, the following vulnerability has been resolved:
ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.
The bug is in ipc_idr_alloc() in the checkpoint/restore path.
-
ids->next_id is passed to:
idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)
-
The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range.
-
The new object id is still encoded with the narrower SysV IPC index width:
new->id = (new->seq << ipcmni_seq_shift()) + idx
-
Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id)
That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.
-
For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.
-
A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.
Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.
{
"affected": [],
"aliases": [
"CVE-2026-52923"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-825"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T08:16:22Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipc: limit next_id allocation to the valid ID range\n\nThe checkpoint/restore sysctl path can request the next SysV IPC id\nthrough ids-\u003enext_id. ipc_idr_alloc() currently forwards that request to\nidr_alloc() with an open-ended upper bound.\n\nIf the valid tail of the SysV IPC id space is full, the allocation can\nspill beyond ipc_mni. The returned SysV IPC id still uses the normal\nindex encoding, so later lookup and removal can target the wrong slot. \nThis leaves the real IDR entry behind and breaks the IDR state for the\nobject.\n\nThe bug is in ipc_idr_alloc() in the checkpoint/restore path.\n\n1. ids-\u003enext_id is passed to:\n\n idr_alloc(\u0026ids-\u003eipcs_idr, new, ipcid_to_idx(next_id), 0, ...)\n\n2. The zero upper bound makes the allocation effectively open-ended.\n Once the valid SysV IPC tail is occupied, idr_alloc() can spill past\n ipc_mni and allocate an entry beyond the valid IPC id range.\n\n3. The new object id is still encoded with the narrower SysV IPC index\n width:\n\n new-\u003eid = (new-\u003eseq \u003c\u003c ipcmni_seq_shift()) + idx\n\n4. Later removal goes through ipc_rmid(), which uses:\n\n ipcid_to_idx(ipcp-\u003eid)\n\n That truncates the real IDR index. An object actually stored at a\n high index can then be removed as if it lived at a low in-range\n index.\n\n5. For shared memory, shm_destroy() frees the current object anyway, but\n the real high IDR slot is left behind as a dangling pointer.\n\n6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry\n and dereferences freed memory.\n\nPrevent this by bounding the requested allocation to ipc_mni so the\ncheckpoint/restore path fails once the valid range is exhausted.",
"id": "GHSA-m237-4jxg-w5jh",
"modified": "2026-06-30T03:37:10Z",
"published": "2026-06-24T09:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52923"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-52923"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492094"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/157ce2c6836ce0ff19108a819f38df061345425f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bbe2bb9111ce6967a951bfac79af142d816fae5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41058d4c3f63ab64901560a704882e0565f4e456"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c58a92849175f5e2ab7bc2734b3b89afe79f6ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3cc795129e5ec0f8948653a3bf471e7d8852f5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af24e202b543ded8a34f1d5d3db54eb916173f04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd4be70669af55b974860d13680348cfdf50bbed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa0b9b2b7ae3539908d69c2b9ac0d144d9bc5139"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52923.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M287-FGWG-4XPC
Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31A vulnerability in the IKEv2 feature of Cisco Secure Firewall ASA Software and Cisco Secure FTD Software could allow an unauthenticated, remote attacker to cause a DoS condition on an affected device that may impact the availability of services to devices elsewhere in the network.
This vulnerability is due to a memory leak when parsing IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to exhaust resources, causing a DoS condition that will eventually require the device to be manually reloaded.
{
"affected": [],
"aliases": [
"CVE-2026-20015"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T18:16:15Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the IKEv2 feature of Cisco Secure Firewall ASA Software and Cisco Secure FTD Software could allow an unauthenticated, remote attacker to cause a DoS condition on an affected device that may impact the availability of services to devices elsewhere in the network.\n\n This vulnerability is due to a memory leak when parsing IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to exhaust resources, causing a DoS condition that will eventually require the device to be manually reloaded.",
"id": "GHSA-m287-fgwg-4xpc",
"modified": "2026-03-04T18:31:54Z",
"published": "2026-03-04T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20015"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ikev2-dos-eBueGdEG"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-M28W-5Q4V-5M48
Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-22 21:31In the Linux kernel, the following vulnerability has been resolved:
KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying
When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN.
For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU.
Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless.
The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be any userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.
{
"affected": [],
"aliases": [
"CVE-2026-53345"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T14:16:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don\u0027t WARN if memory is dirtied without a vCPU when the VM is dying\n\nWhen marking a page dirty, complain about not having a running/loaded vCPU\nif and only if the VM is still alive, i.e. its refcount is non-zero. This\nwill allow fixing a memory leak for x86 SEV-ES guests without hitting what\nis effectively a false positive on the WARN.\n\nFor some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page\nacross an exit to userspace, and typically unmaps the page on the next\nKVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM\nneeds to unmap the page when the vCPU is destroyed, which in turn triggers\nthe WARN about not having a running vCPU.\n\nAlternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,\nas is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;\nsuppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But\nloading a vCPU during destruction is gross (ideally nVMX code would be\ncleaned up), risks complicating the SEV-ES code (KVM would need to ensure\nthe temporarily load()+put() only runs when the vCPU isn\u0027t already loaded),\nand is ultimately pointless.\n\nThe motivation for the WARN is to guard against KVM dirtying guest memory\nwithout pushing the corresponding GFN to the active vCPU\u0027s dirty ring, e.g.\nto ensure userspace doesn\u0027t miss a dirty page. But for the VM\u0027s refcount\nto reach zero, there can\u0027t be _any_ userspace mappings to the dirty ring,\nas mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if\nuserspace had a valid mapping for the dirty ring, then the vCPU file and\nthus the owning VM would still be alive. And so since userspace can\u0027t\npossibly reach the dirty ring, whether or not KVM technically \"misses\" a\npush to the dirty ring is irrelevant.",
"id": "GHSA-m28w-5q4v-5m48",
"modified": "2026-07-22T21:31:46Z",
"published": "2026-07-01T15:35:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53345"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/033d39e41fc30f484f4e4f37fb4cd76b12cbb18e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/343e95c8ecc40e0738975ef4ee24c0c35e800e6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66a8e7ddd901023c89a2733494d827eca3f9c1b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8618004d3e897c0f1b71d9a9ab860461289bb89a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99d7d43784ae3235026581e9bf892c036e04c8e6"
}
],
"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-M2MF-QQPM-8VCH
Vulnerability from github – Published: 2025-08-11 06:30 – Updated: 2025-08-11 06:30in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory.
{
"affected": [],
"aliases": [
"CVE-2025-27562"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-11T04:15:40Z",
"severity": "LOW"
},
"details": "in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory.",
"id": "GHSA-m2mf-qqpm-8vch",
"modified": "2025-08-11T06:30:31Z",
"published": "2025-08-11T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27562"
},
{
"type": "WEB",
"url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2025/2025-07.md"
}
],
"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"
}
]
}
GHSA-M2R3-WMC2-RQ6Q
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-02 21:31In the Linux kernel, the following vulnerability has been resolved:
media: hi846: Fix memleak in hi846_init_controls()
hi846_init_controls doesn't clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly.
{
"affected": [],
"aliases": [
"CVE-2023-53300"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: hi846: Fix memleak in hi846_init_controls()\n\nhi846_init_controls doesn\u0027t clean the allocated ctrl_hdlr\nin case there is a failure, which causes memleak. Add\nv4l2_ctrl_handler_free to free the resource properly.",
"id": "GHSA-m2r3-wmc2-rq6q",
"modified": "2025-12-02T21:31:26Z",
"published": "2025-09-16T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53300"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07f0f15e5db60c5b0722049d3251ef4a46dc3b76"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12a80b1490e398f5ad7157508cf32b73511de5fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2649c1a20e8e399ee955d0e22192f9992662c3d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd22e8c8c38fb40f130d3a60e52c59996a5bbae9"
}
],
"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-M37R-WP9G-CFGF
Vulnerability from github – Published: 2021-12-24 00:00 – Updated: 2022-01-04 00:01A vulnerability was found in Privoxy which was fixed in process_encrypted_request_headers() by freeing header memory when failing to get the request destination.
{
"affected": [],
"aliases": [
"CVE-2021-44541"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-23T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in Privoxy which was fixed in process_encrypted_request_headers() by freeing header memory when failing to get the request destination.",
"id": "GHSA-m37r-wp9g-cfgf",
"modified": "2022-01-04T00:01:15Z",
"published": "2021-12-24T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44541"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/3.0.33/user-manual/whatsnew.html,"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/gitweb/?p=privoxy.git;a=commit;h=652b4b7cb0"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-M3J7-R27P-7M78
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg
ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpi_object. The acpi_evaluate_dsm() returned acpi_object to be freed.
Free the acpi_object after use.
{
"affected": [],
"aliases": [
"CVE-2022-49855"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg\n\nipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to\nobtain the wwan power state configuration from BIOS but is\nnot freeing the acpi_object. The acpi_evaluate_dsm() returned\nacpi_object to be freed.\n\nFree the acpi_object after use.",
"id": "GHSA-m3j7-r27p-7m78",
"modified": "2025-05-07T15:31:25Z",
"published": "2025-05-01T15:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49855"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13b1ea861e8aeb701bcfbfe436b943efa2d44029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7560ceef4d2832a67e8781d924e129c7f542376f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d38a648d2d6cc7bee11c6f533ff9426a00c2a74c"
}
],
"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-M3M6-8JJ6-96Q6
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-03 21:30In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()
The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only.
{
"affected": [],
"aliases": [
"CVE-2022-50321"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()\n\nThe brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb\nin case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.\nCompile tested only.",
"id": "GHSA-m3m6-8jj6-96q6",
"modified": "2025-12-03T21:30:59Z",
"published": "2025-09-15T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50321"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/212fde3fe76e962598ce1d47b97cc78afdfc71b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a4d18318f473e97d628f410215b3fac32d07aed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c55fdebc1c358de96bfab52ed309d58a3ba66ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f159116d620615779adbf88a5d94713702216d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d869a189505224601e310c7769cb90b0e2f60b31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e08e6812efb6a8c676e733de0518594d1517e0d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5d01e85cf46628647cd696cb72ba4659b18967f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8ef89e5b89ee041a94eecfb6c31fcc237f9168c"
}
],
"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-M43Q-5C9P-X5FH
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35There are several memory leaks in the MIFF coder in /coders/miff.c due to improper image depth values, which can be triggered by a specially crafted input file. These leaks could potentially lead to an impact to application availability or cause a denial of service. It was originally reported that the issues were in AcquireMagickMemory() because that is where LeakSanitizer detected the leaks, but the patch resolves issues in the MIFF coder, which incorrectly handles data being passed to AcquireMagickMemory(). This flaw affects ImageMagick versions prior to 7.0.9-0.
{
"affected": [],
"aliases": [
"CVE-2020-27753"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-08T22:15:00Z",
"severity": "MODERATE"
},
"details": "There are several memory leaks in the MIFF coder in /coders/miff.c due to improper image depth values, which can be triggered by a specially crafted input file. These leaks could potentially lead to an impact to application availability or cause a denial of service. It was originally reported that the issues were in `AcquireMagickMemory()` because that is where LeakSanitizer detected the leaks, but the patch resolves issues in the MIFF coder, which incorrectly handles data being passed to `AcquireMagickMemory()`. This flaw affects ImageMagick versions prior to 7.0.9-0.",
"id": "GHSA-m43q-5c9p-x5fh",
"modified": "2022-05-24T17:35:39Z",
"published": "2022-05-24T17:35:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27753"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1894229"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.