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.
2232 vulnerabilities reference this CWE, most recent first.
GHSA-X2PV-VMM7-RHWR
Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31A vulnerability in the Remote Access SSL VPN functionality of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an authenticated, remote attacker with a valid VPN connection to exhaust device memory resulting in a denial of service (DoS) condition.This does not affect the management or MUS interfaces.
This vulnerability is due to trusting user input without validation. An attacker could exploit this vulnerability by sending crafted packets to the Remote Access SSL VPN server. A successful exploit could allow the attacker to cause the device to reload, resulting in a DoS condition.
{
"affected": [],
"aliases": [
"CVE-2026-20105"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T18:16:26Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Remote Access SSL VPN functionality of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an authenticated, remote attacker with a valid VPN connection to exhaust device memory resulting in a denial of service (DoS) condition.This does not affect the management or MUS interfaces.\n\n This vulnerability is due to trusting user input without validation. An attacker could exploit this vulnerability by sending crafted packets to the Remote Access SSL VPN server. A successful exploit could allow the attacker to cause the device to reload, resulting in a DoS condition.",
"id": "GHSA-x2pv-vmm7-rhwr",
"modified": "2026-03-04T18:31:56Z",
"published": "2026-03-04T18:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20105"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-m9sx6MbC"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X2XJ-658J-798F
Vulnerability from github – Published: 2024-08-21 03:31 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().
{
"affected": [],
"aliases": [
"CVE-2024-43871"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T01:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\n\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().",
"id": "GHSA-x2xj-658j-798f",
"modified": "2026-05-12T12:32:04Z",
"published": "2024-08-21T03:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43dc6c87c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd50a974097bb82d52a458bd3ee39fb723129a0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X37F-9GM8-PV63
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
drm/hyperv: Fix address space leak when Hyper-V DRM device is removed
When a Hyper-V DRM device is probed, the driver allocates MMIO space for the vram, and maps it cacheable. If the device removed, or in the error path for device probing, the MMIO space is released but no unmap is done. Consequently the kernel address space for the mapping is leaked.
Fix this by adding iounmap() calls in the device removal path, and in the error path during device probing.
{
"affected": [],
"aliases": [
"CVE-2025-21978"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/hyperv: Fix address space leak when Hyper-V DRM device is removed\n\nWhen a Hyper-V DRM device is probed, the driver allocates MMIO space for\nthe vram, and maps it cacheable. If the device removed, or in the error\npath for device probing, the MMIO space is released but no unmap is done.\nConsequently the kernel address space for the mapping is leaked.\n\nFix this by adding iounmap() calls in the device removal path, and in the\nerror path during device probing.",
"id": "GHSA-x37f-9gm8-pv63",
"modified": "2025-11-03T21:33:26Z",
"published": "2025-04-01T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21978"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/158242b56bf465a73e1edeac0fe828a8acad4499"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24f1bbfb2be77dad82489c1468bbb14312aab129"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad27b4a51495490b815580d9b935e8eee14d1a9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed709355fd05ef747e1af24a1d5d78cd7feb81e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c40cd24bfb9bfbb315c118ca14ebe6cf52e2dd1e"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-X37Q-QW63-QF28
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.
{
"affected": [],
"aliases": [
"CVE-2025-39737"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0027t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.",
"id": "GHSA-x37q-qw63-qf28",
"modified": "2026-05-12T15:31:05Z",
"published": "2025-09-11T18:35:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ef72a7fedc5bca70e8cc980985790de10d407aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d2d22a55ffe35c38e69795468a7addd1a80e9ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/926092268efdf1ed7b55cf486356c74a9e7710d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b80430c194e4a114dc663c1025d56b4f3d0153d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f1f4e95031f84867c5821540466d62f88dab8ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a04de4c40aab9b338dfa989cf4aec70fd187eeb2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1534ae23c2b6be350c8ab060803fbf6e9682adc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e21a3ddd58733ce31afcb1e5dc3cb80a4b5bc29b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f014c10d190b92aad366e56b445daffcd1c075e4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-X3CP-9CGR-M6GC
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-19 18:31In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Mark target gfn of emulated atomic instruction as dirty
When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty.
Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase.
Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit.
Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging.
base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
{
"affected": [],
"aliases": [
"CVE-2024-35804"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Mark target gfn of emulated atomic instruction as dirty\n\nWhen emulating an atomic access on behalf of the guest, mark the target\ngfn dirty if the CMPXCHG by KVM is attempted and doesn\u0027t fault. This\nfixes a bug where KVM effectively corrupts guest memory during live\nmigration by writing to guest memory without informing userspace that the\npage is dirty.\n\nMarking the page dirty got unintentionally dropped when KVM\u0027s emulated\nCMPXCHG was converted to do a user access. Before that, KVM explicitly\nmapped the guest page into kernel memory, and marked the page dirty during\nthe unmap phase.\n\nMark the page dirty even if the CMPXCHG fails, as the old data is written\nback on failure, i.e. the page is still written. The value written is\nguaranteed to be the same because the operation is atomic, but KVM\u0027s ABI\nis that all writes are dirty logged regardless of the value written. And\nmore importantly, that\u0027s what KVM did before the buggy commit.\n\nHuge kudos to the folks on the Cc list (and many others), who did all the\nactual work of triaging and debugging.\n\nbase-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64",
"id": "GHSA-x3cp-9cgr-m6gc",
"modified": "2025-09-19T18:31:17Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35804"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66"
}
],
"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-X3WV-3WJ6-MVVV
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix memory leak in amdgpu_ras_init()
When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function returns directly without freeing the allocated con structure, leading to a memory leak.
Fix this by jumping to the release_con label to properly clean up the allocated memory before returning the error code.
Compile tested only. Issue found using a prototype static analysis tool and code review.
{
"affected": [],
"aliases": [
"CVE-2026-45976"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in amdgpu_ras_init()\n\nWhen amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function\nreturns directly without freeing the allocated con structure, leading\nto a memory leak.\n\nFix this by jumping to the release_con label to properly clean up the\nallocated memory before returning the error code.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.",
"id": "GHSA-x3wv-3wj6-mvvv",
"modified": "2026-06-16T03:30:33Z",
"published": "2026-05-27T15:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45976"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fef8c2ac67e7c1b0409d23653300b134c63e54c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f43e7812b30d6b2e850218f9bb1dae60727fcef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c11cd77a18115d2cd3f4b6915c4a537b6042f950"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee41e5b63c8210525c936ee637a2c8d185ce873c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8a5426652bdadd4a5cb48326d48abbdfebe8153"
}
],
"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-X3XW-8J27-57GC
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: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()
When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested.
{
"affected": [],
"aliases": [
"CVE-2022-49857"
],
"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: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()\n\nWhen prestera_sdma_switch_init() failed, the memory pointed to by\nsw-\u003erxtx isn\u0027t released. Fix it. Only be compiled, not be tested.",
"id": "GHSA-x3xw-8j27-57gc",
"modified": "2025-05-07T15:31:25Z",
"published": "2025-05-01T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49857"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31e5084ac6876e52dbb0a1cc4fc18b6c79979f31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/409731df6310a33f4d0a3ef594d2410cdcd637f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/519b58bbfa825f042fcf80261cc18e1e35f85ffd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5333cf1b7f6861912aff6263978d4781f9858e47"
}
],
"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-X45P-M5JM-48HC
Vulnerability from github – Published: 2025-10-23 18:31 – Updated: 2025-10-23 18:31FontForge v20230101 was discovered to contain a memory leak via the utf7toutf8_copy function at /fontforge/sfd.c.
{
"affected": [],
"aliases": [
"CVE-2025-50951"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-23T16:16:33Z",
"severity": "HIGH"
},
"details": "FontForge v20230101 was discovered to contain a memory leak via the utf7toutf8_copy function at /fontforge/sfd.c.",
"id": "GHSA-x45p-m5jm-48hc",
"modified": "2025-10-23T18:31:14Z",
"published": "2025-10-23T18:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50951"
},
{
"type": "WEB",
"url": "https://github.com/fontforge/fontforge/pull/5495"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X4F6-7RHV-JQW4
Vulnerability from github – Published: 2026-10-13 21:34 – Updated: 2026-10-13 21:34Missing release of memory after effective lifetime in Remote Desktop Gateway Service allows an unauthorized attacker to deny service over a network.
{
"affected": [],
"aliases": [
"CVE-2026-70033"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-13T19:19:14Z",
"severity": "HIGH"
},
"details": "Missing release of memory after effective lifetime in Remote Desktop Gateway Service allows an unauthorized attacker to deny service over a network.",
"id": "GHSA-x4f6-7rhv-jqw4",
"modified": "2026-10-13T21:34:00Z",
"published": "2026-10-13T21:34:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70033"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70033"
}
],
"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-X4V9-V29C-XH9H
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-25 15:31In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Fix memory leak on codec_info allocation failure
In wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codec_info fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak.
Fix this by calling kfree() on the instance in this error path to ensure it is properly released.
{
"affected": [],
"aliases": [
"CVE-2026-45928"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: chips-media: wave5: Fix memory leak on codec_info allocation failure\n\nIn wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is\nallocated via kzalloc(). If the subsequent allocation for inst-\u003ecodec_info\nfails, the functions return -ENOMEM without freeing the previously\nallocated instance, causing a memory leak.\n\nFix this by calling kfree() on the instance in this error path to ensure\nit is properly released.",
"id": "GHSA-x4v9-v29c-xh9h",
"modified": "2026-06-25T15:31:43Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45928"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1de71556cbd6e1d0d26fb86b9b3bb8caa0df8495"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32e9e45cf7e3422d21fa64535588d3572faf71c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52defdd4034db1a34bb48006f889d66a3629224b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a519e21e32398459ba357e67b541402f7295ee1b"
}
],
"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.