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.
2128 vulnerabilities reference this CWE, most recent first.
GHSA-RW87-JQJ5-Q35F
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31In VMware ESXi (6.7 before ESXi670-201908101-SG, 6.5 before ESXi650-202007101-SG), Workstation (15.x before 15.1.0), Fusion (11.x before 11.1.0), the VMCI host drivers used by VMware hypervisors contain a memory leak vulnerability. A malicious actor with access to a virtual machine may be able to trigger a memory leak issue resulting in memory resource exhaustion on the hypervisor if the attack is sustained for extended periods of time.
{
"affected": [],
"aliases": [
"CVE-2020-3995"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-20T17:15:00Z",
"severity": "MODERATE"
},
"details": "In VMware ESXi (6.7 before ESXi670-201908101-SG, 6.5 before ESXi650-202007101-SG), Workstation (15.x before 15.1.0), Fusion (11.x before 11.1.0), the VMCI host drivers used by VMware hypervisors contain a memory leak vulnerability. A malicious actor with access to a virtual machine may be able to trigger a memory leak issue resulting in memory resource exhaustion on the hypervisor if the attack is sustained for extended periods of time.",
"id": "GHSA-rw87-jqj5-q35f",
"modified": "2022-05-24T17:31:50Z",
"published": "2022-05-24T17:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3995"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2020-0023.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RWC9-H9MH-XFWQ
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-09-14 12:31In the Linux kernel, the following vulnerability has been resolved:
of: unittest: Fix memory leak in unittest_data_add()
In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak.
Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths.
For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.
{
"affected": [],
"aliases": [
"CVE-2026-23137"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nof: unittest: Fix memory leak in unittest_data_add()\n\nIn unittest_data_add(), if of_resolve_phandles() fails, the allocated\nunittest_data is not freed, leading to a memory leak.\n\nFix this by using scope-based cleanup helper __free(kfree) for automatic\nresource cleanup. This ensures unittest_data is automatically freed when\nit goes out of scope in error paths.\n\nFor the success path, use retain_and_null_ptr() to transfer ownership\nof the memory to the device tree and prevent double freeing.",
"id": "GHSA-rwc9-h9mh-xfwq",
"modified": "2026-09-14T12:31:28Z",
"published": "2026-02-14T18:30:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23137"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/235a1eb8d2dcc49a6cf0a5ee1aa85544a5d0054b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58baf98d1bdab897fd796f39a16061bade229d71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f09b0f705bd7197863b90256ef533a6414d1db2c"
}
],
"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-RWHM-C36W-484H
Vulnerability from github – Published: 2026-07-06 15:30 – Updated: 2026-07-09 15:32A memory leak in OpenVPN version 2.5.0 through 2.5.11, 2.6.0 through 2.6.20 and 2.7_alpha1 through 2.7.4 allows remote attackers with a valid tls-crypt-v2 client key to potentially cause a denial of service
{
"affected": [],
"aliases": [
"CVE-2026-13698"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-06T15:16:35Z",
"severity": "MODERATE"
},
"details": "A memory leak in OpenVPN version 2.5.0 through 2.5.11, 2.6.0 through 2.6.20 and 2.7_alpha1 through 2.7.4 allows remote attackers with a valid tls-crypt-v2 client key to potentially cause a denial of service",
"id": "GHSA-rwhm-c36w-484h",
"modified": "2026-07-09T15:32:19Z",
"published": "2026-07-06T15:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13698"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/Security%20Announcements/CVE-2026-13698"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/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-RWHV-4JCG-G276
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: Fix memory leak in management tx
In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic.
Kmemleak reports this problem as below,
unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20
Free the memory during completion and cleanup to fix the leak.
Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
{
"affected": [],
"aliases": [
"CVE-2024-50236"
],
"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\nwifi: ath10k: Fix memory leak in management tx\n\nIn the current logic, memory is allocated for storing the MSDU context\nduring management packet TX but this memory is not being freed during\nmanagement TX completion. Similar leaks are seen in the management TX\ncleanup logic.\n\nKmemleak reports this problem as below,\n\nunreferenced object 0xffffff80b64ed250 (size 16):\n comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s)\n hex dump (first 16 bytes):\n 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......\n backtrace:\n [\u003cffffffe6e7b245dc\u003e] __kmem_cache_alloc_node+0x1e4/0x2d8\n [\u003cffffffe6e7adde88\u003e] kmalloc_trace+0x48/0x110\n [\u003cffffffe6bbd765fc\u003e] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]\n [\u003cffffffe6bbd3eed4\u003e] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]\n [\u003cffffffe6e78d5974\u003e] process_scheduled_works+0x1ac/0x400\n [\u003cffffffe6e78d60b8\u003e] worker_thread+0x208/0x328\n [\u003cffffffe6e78dc890\u003e] kthread+0x100/0x1c0\n [\u003cffffffe6e78166c0\u003e] ret_from_fork+0x10/0x20\n\nFree the memory during completion and cleanup to fix the leak.\n\nProtect the mgmt_pending_tx idr_remove() operation in\nath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-\u003edata_lock similar to\nother instances.\n\nTested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1",
"id": "GHSA-rwhv-4jcg-g276",
"modified": "2025-11-04T00:31:59Z",
"published": "2024-11-09T12:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50236"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f6f1e26ac6d2b38e2198a71f81f0ade14d6b07b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4112450da7d67b59ccedc2208bae622db17dbcb8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f5a939759c79e7385946c85e62feca51a18d816"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cc23898e6ba47e976050d3c080b4d2c1add3748"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fc9af3df6ca7f3c94774d20f62dc7b49616026d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/705be2dc45c7f852e211e16bc41a916fab741983"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e15d84b3bba187aa372dff7c58ce1fd5cb48a076"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eff818238bedb9c2484c251ec46f9f160911cdc0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RWQ6-CRJG-9CPW
Vulnerability from github – Published: 2024-09-05 16:44 – Updated: 2024-09-09 14:05When a canister method is called via ic_cdk::call*, a new Future CallFuture is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called CallFutureState. A bug in the polling implementation of the CallFuture allows multiple references to be held for this internal state and not all references were dropped before the Future is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak.
Impact
Canisters built in Rust with ic_cdk and ic_cdk_timers are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. In the worst case, this could lead to heap memory exhaustion triggered by an attacker.
Motoko based canisters are not affected by the bug.
Patches
The patch has been backported to all minor versions between >= 0.8.0, <= 0.15.0. The patched versions available are 0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1 and their previous versions have been yanked.
Workarounds
There are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of ic_cdk to avoid running out of Wasm heap memory.
[!NOTE]
Upgrading the canisters (without updatingic_cdk) also frees the leaked memory but it's only a temporary solution.
References
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.8.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"fixed": "0.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 0.11.5"
},
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.11.0"
},
{
"fixed": "0.11.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.0"
},
{
"fixed": "0.12.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 0.13.4"
},
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.13.0"
},
{
"fixed": "0.13.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.14.0"
},
{
"fixed": "0.14.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ic_cdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.15.0"
},
{
"fixed": "0.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-7884"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-05T16:44:27Z",
"nvd_published_at": "2024-09-05T13:15:11Z",
"severity": "HIGH"
},
"details": "When a canister method is called via `ic_cdk::call*`, a new Future `CallFuture` is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called `CallFutureState`. A bug in the polling implementation of the `CallFuture` allows multiple references to be held for this internal state and not all references were dropped before the `Future` is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister\u0027s heap and thus causing a memory leak. \n\n### Impact\nCanisters built in Rust with `ic_cdk` and `ic_cdk_timers` are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. **In the worst case, this could lead to heap memory exhaustion triggered by an attacker.**\n\nMotoko based canisters are not affected by the bug.\n\n### Patches\nThe patch has been backported to all minor versions between `\u003e= 0.8.0, \u003c= 0.15.0`. The patched versions available are `0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1` and their previous versions have been yanked. \n\n### Workarounds\nThere are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of `ic_cdk` to avoid running out of Wasm heap memory. \n\n\u003e [!NOTE] \n\u003e Upgrading the canisters (without updating `ic_cdk`) also frees the leaked memory but it\u0027s only a temporary solution.\n\n### References\n- [dfinity/cdk-rs/pull/509](https://github.com/dfinity/cdk-rs/pull/509)\n- [ic_cdk docs](https://docs.rs/ic-cdk/latest/ic_cdk/)\n- [Internet Computer Specification](https://internetcomputer.org/docs/current/references/ic-interface-spec)",
"id": "GHSA-rwq6-crjg-9cpw",
"modified": "2024-09-09T14:05:39Z",
"published": "2024-09-05T16:44:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dfinity/cdk-rs/security/advisories/GHSA-rwq6-crjg-9cpw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7884"
},
{
"type": "WEB",
"url": "https://github.com/dfinity/cdk-rs/pull/509"
},
{
"type": "WEB",
"url": "https://github.com/dfinity/cdk-rs/commit/bd17d57a7b8ca59665fea5fad6143ca02724d03b"
},
{
"type": "WEB",
"url": "https://docs.rs/ic-cdk/latest/ic_cdk"
},
{
"type": "PACKAGE",
"url": "https://github.com/dfinity/cdk-rs"
},
{
"type": "WEB",
"url": "https://internetcomputer.org/docs/current/references/ic-interface-spec"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0372.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "ic-cdk has a memory leak when calling a canister method via `ic_cdk::call`"
}
GHSA-RWQH-F7G9-W86H
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-04 15:35In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix DMA fence leak
In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref counter to 1. Then, dma_resv_add_fence() gets a second reference, and a pointer to the ffs_dma_fence is passed as the usb_request's "context" field.
The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffs_dmabuf_cleanup() function decreases the reference count, but only to balance with the reference grab in ffs_dmabuf_signal_done().
The code will then slowly leak memory as more ffs_dma_fence objects are created without being ever freed.
Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dma_fence_put() right after dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded after being signalled.
{
"affected": [],
"aliases": [
"CVE-2026-64328"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Fix DMA fence leak\n\nIn ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc\u0027d, with the\nunderlying dma_fence later initialized by dma_fence_init(), which sets\nits kref counter to 1. Then, dma_resv_add_fence() gets a second\nreference, and a pointer to the ffs_dma_fence is passed as the\nusb_request\u0027s \"context\" field.\n\nThe dma-resv mechanism will manage the second reference, but the first\nreference is never properly released; the ffs_dmabuf_cleanup() function\ndecreases the reference count, but only to balance with the reference\ngrab in ffs_dmabuf_signal_done().\n\nThe code will then slowly leak memory as more ffs_dma_fence objects are\ncreated without being ever freed.\n\nAddress this issue by transferring ownership of the fence to the DMA\nreservation object, by calling dma_fence_put() right after\ndma_resv_add_fence(). The ffs_dma_fence then gets properly discarded\nafter being signalled.",
"id": "GHSA-rwqh-f7g9-w86h",
"modified": "2026-09-04T15:35:50Z",
"published": "2026-07-25T12:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64328"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0cae3d6109427c455bad0a18dfb3e2a91657e38a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7475b2dce5e121e687280ba5732ccefe77ffd2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/baa6b6068a3f2bf2ed525a1cb37975905dadc658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e086c16962a1b0142e2675610e9c06fcfcd4c3a8"
}
],
"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-RWQR-MQ87-5P2C
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-20 18:31In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in alloc_wbufs()
kmemleak reported a sequence of memory leaks, and show them as following:
unreferenced object 0xffff8881575f8400 (size 1024): comm "mount", pid 19625, jiffies 4297119604 (age 20.383s) 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: [] __kmalloc+0x4d/0x150 [] ubifs_mount+0x307b/0x7170 [ubifs] [] legacy_get_tree+0xed/0x1d0 [] vfs_get_tree+0x7d/0x230 [] path_mount+0xdd4/0x17b0 [] __x64_sys_mount+0x1fa/0x270 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff8881798a6e00 (size 512): comm "mount", pid 19677, jiffies 4297121912 (age 37.816s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace: [] __kmalloc+0x4d/0x150 [] ubifs_wbuf_init+0x52/0x480 [ubifs] [] ubifs_mount+0x31f5/0x7170 [ubifs] [] legacy_get_tree+0xed/0x1d0 [] vfs_get_tree+0x7d/0x230 [] path_mount+0xdd4/0x17b0 [] __x64_sys_mount+0x1fa/0x270 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0
The problem is that the ubifs_wbuf_init() returns an error in the loop which in the alloc_wbufs(), then the wbuf->buf and wbuf->inodes that were successfully alloced before are not freed.
Fix it by adding error hanging path in alloc_wbufs() which frees the memory alloced before when ubifs_wbuf_init() returns an error.
{
"affected": [],
"aliases": [
"CVE-2023-53468"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix memory leak in alloc_wbufs()\n\nkmemleak reported a sequence of memory leaks, and show them as following:\n\n unreferenced object 0xffff8881575f8400 (size 1024):\n comm \"mount\", pid 19625, jiffies 4297119604 (age 20.383s)\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:\n [\u003cffffffff8176cecd\u003e] __kmalloc+0x4d/0x150\n [\u003cffffffffa0406b2b\u003e] ubifs_mount+0x307b/0x7170 [ubifs]\n [\u003cffffffff819fa8fd\u003e] legacy_get_tree+0xed/0x1d0\n [\u003cffffffff81936f2d\u003e] vfs_get_tree+0x7d/0x230\n [\u003cffffffff819b2bd4\u003e] path_mount+0xdd4/0x17b0\n [\u003cffffffff819b37aa\u003e] __x64_sys_mount+0x1fa/0x270\n [\u003cffffffff83c14295\u003e] do_syscall_64+0x35/0x80\n [\u003cffffffff83e0006a\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n unreferenced object 0xffff8881798a6e00 (size 512):\n comm \"mount\", pid 19677, jiffies 4297121912 (age 37.816s)\n hex dump (first 32 bytes):\n 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n backtrace:\n [\u003cffffffff8176cecd\u003e] __kmalloc+0x4d/0x150\n [\u003cffffffffa0418342\u003e] ubifs_wbuf_init+0x52/0x480 [ubifs]\n [\u003cffffffffa0406ca5\u003e] ubifs_mount+0x31f5/0x7170 [ubifs]\n [\u003cffffffff819fa8fd\u003e] legacy_get_tree+0xed/0x1d0\n [\u003cffffffff81936f2d\u003e] vfs_get_tree+0x7d/0x230\n [\u003cffffffff819b2bd4\u003e] path_mount+0xdd4/0x17b0\n [\u003cffffffff819b37aa\u003e] __x64_sys_mount+0x1fa/0x270\n [\u003cffffffff83c14295\u003e] do_syscall_64+0x35/0x80\n [\u003cffffffff83e0006a\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe problem is that the ubifs_wbuf_init() returns an error in the\nloop which in the alloc_wbufs(), then the wbuf-\u003ebuf and wbuf-\u003einodes\nthat were successfully alloced before are not freed.\n\nFix it by adding error hanging path in alloc_wbufs() which frees\nthe memory alloced before when ubifs_wbuf_init() returns an error.",
"id": "GHSA-rwqr-mq87-5p2c",
"modified": "2026-01-20T18:31:51Z",
"published": "2025-10-01T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26ec45f1c504e15268383019df139d7983f1e67f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a1ff3c5d04b9079b4f768d9a71b51c4af578dd2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf50229494f0443b3f08427d7df63e5a7e2a796a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185"
}
],
"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-RWR3-HM95-VV7P
Vulnerability from github – Published: 2022-05-03 00:00 – Updated: 2022-05-11 00:01A memory leak was discovered in matio 1.5.21 and earlier in Mat_VarReadNextInfo5() in mat5.c via a crafted file. This issue can potentially result in DoS.
{
"affected": [],
"aliases": [
"CVE-2022-1515"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-02T19:15:00Z",
"severity": "MODERATE"
},
"details": "A memory leak was discovered in matio 1.5.21 and earlier in Mat_VarReadNextInfo5() in mat5.c via a crafted file. This issue can potentially result in DoS.",
"id": "GHSA-rwr3-hm95-vv7p",
"modified": "2022-05-11T00:01:57Z",
"published": "2022-05-03T00:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1515"
},
{
"type": "WEB",
"url": "https://github.com/tbeu/matio/issues/186"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2079986"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RX6X-4FRG-6JXM
Vulnerability from github – Published: 2025-09-23 21:30 – Updated: 2025-09-23 21:30In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix mpol_new leak in shared_policy_replace
If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation.
This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time:
shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
{
"affected": [],
"aliases": [
"CVE-2022-49080"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix mpol_new leak in shared_policy_replace\n\nIf mpol_new is allocated but not used in restart loop, mpol_new will be\nfreed via mpol_put before returning to the caller. But refcnt is not\ninitialized yet, so mpol_put could not do the right things and might\nleak the unused mpol_new. This would happen if mempolicy was updated on\nthe shared shmem file while the sp-\u003elock has been dropped during the\nmemory allocation.\n\nThis issue could be triggered easily with the below code snippet if\nthere are many processes doing the below work at the same time:\n\n shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);\n shm = shmat(shmid, 0, 0);\n loop many times {\n mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);\n mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,\n maxnode, 0);\n }",
"id": "GHSA-rx6x-4frg-6jxm",
"modified": "2025-09-23T21:30:54Z",
"published": "2025-09-23T21:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651"
}
],
"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-RXFW-48WV-X4RF
Vulnerability from github – Published: 2025-08-14 18:31 – Updated: 2025-08-14 18:31A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper parsing of IKEv2 packets. An attacker could exploit this vulnerability by sending a continuous stream of crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to partially exhaust system memory, causing system instability like being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition.
{
"affected": [],
"aliases": [
"CVE-2025-20254"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T17:15:39Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.\n\n This vulnerability is due to improper parsing of IKEv2 packets. An attacker could exploit this vulnerability by sending a continuous stream of crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to partially exhaust system memory, causing system instability like being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition.",
"id": "GHSA-rxfw-48wv-x4rf",
"modified": "2025-08-14T18:31:30Z",
"published": "2025-08-14T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20254"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-ios-dos-DOESHWHy"
}
],
"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"
}
]
}
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.