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.
2124 vulnerabilities reference this CWE, most recent first.
GHSA-PHX3-79H9-XHVQ
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe().
Switch to the managed version to fix both issues.
{
"affected": [],
"aliases": [
"CVE-2024-35833"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA\n\nThis dma_alloc_coherent() is undone neither in the remove function, nor in\nthe error handling path of fsl_qdma_probe().\n\nSwitch to the managed version to fix both issues.",
"id": "GHSA-phx3-79h9-xhvq",
"modified": "2024-10-29T21:30:45Z",
"published": "2024-05-17T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35833"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-PJ5F-G5WQ-XH99
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:32In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix memory leak in error flow for subscribe event routine
In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak.
{
"affected": [],
"aliases": [
"CVE-2022-49206"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix memory leak in error flow for subscribe event routine\n\nIn case the second xa_insert() fails, the obj_event is not released. Fix\nthe error unwind flow to free that memory to avoid a memory leak.",
"id": "GHSA-pj5f-g5wq-xh99",
"modified": "2025-03-18T21:32:00Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49206"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde"
}
],
"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-PJMJ-JGGX-2J9H
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-02 00:31In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_create()
If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.
{
"affected": [],
"aliases": [
"CVE-2022-50351"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix xid leak in cifs_create()\n\nIf the cifs already shutdown, we should free the xid before return,\notherwise, the xid will be leaked.",
"id": "GHSA-pjmj-jggx-2j9h",
"modified": "2025-12-02T00:31:10Z",
"published": "2025-09-16T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50351"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/593d877c39aa9f3fe1a4b5b022492886d7d700ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92aa09c86ef297976a3c27c6574c0839418dc2c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fee0fb1f15054bb6a0ede452acb42da5bef4d587"
}
],
"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-PJRJ-H4FG-6GM4
Vulnerability from github – Published: 2023-12-05 23:42 – Updated: 2023-12-05 23:42Impact
The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.
Patches
The issue is fixed in version 4.1.0 of tokio-boring.
References
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tokio-boring"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.0.0"
]
}
],
"aliases": [
"CVE-2023-6180"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401",
"CWE-404"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-05T23:42:49Z",
"nvd_published_at": "2023-12-05T15:15:08Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The `set_ex_data` function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.\n\n### Patches\nThe issue is fixed in version 4.1.0 of tokio-boring.\n\n### References\n[CVE-2023-6180 at cve.org](https://www.cve.org/CVERecord?id=CVE-2023-6180)\n",
"id": "GHSA-pjrj-h4fg-6gm4",
"modified": "2023-12-05T23:42:49Z",
"published": "2023-12-05T23:42:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/boring/security/advisories/GHSA-pjrj-h4fg-6gm4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6180"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/boring/commit/a32783374f2682e6949fdb713910b1b9f103d3ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/boring"
}
],
"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": "tokio-boring vulnerable to resource exhaustion via memory leak"
}
GHSA-PM49-6J2C-6857
Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-01-10 00:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix handling of plane refcount
[Why] The mechanism to backup and restore plane states doesn't maintain refcount, which can cause issues if the refcount of the plane changes in between backup and restore operations, such as memory leaks if the refcount was supposed to go down, or double frees / invalid memory accesses if the refcount was supposed to go up.
[How] Cache and re-apply current refcount when restoring plane states.
{
"affected": [],
"aliases": [
"CVE-2024-56775"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T18:15:18Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix handling of plane refcount\n\n[Why]\nThe mechanism to backup and restore plane states doesn\u0027t maintain\nrefcount, which can cause issues if the refcount of the plane changes\nin between backup and restore operations, such as memory leaks if the\nrefcount was supposed to go down, or double frees / invalid memory\naccesses if the refcount was supposed to go up.\n\n[How]\nCache and re-apply current refcount when restoring plane states.",
"id": "GHSA-pm49-6j2c-6857",
"modified": "2025-01-10T00:30:35Z",
"published": "2025-01-08T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27227a234c1487cb7a684615f0749c455218833a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cb2f6793845f135b28361ba8e96901cae3e5790"
}
],
"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-PM4X-JF7F-JMQ6
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-21 00:30In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ...
According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;
After commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.
{
"affected": [],
"aliases": [
"CVE-2026-43068"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-05T16:16:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()\n\nThere\u0027s issue as follows:\n...\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): error count since last fsck: 1\nEXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760\nEXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760\n...\n\nAccording to the log analysis, blocks are always requested from the\ncorrupted block group. This may happen as follows:\next4_mb_find_by_goal\n ext4_mb_load_buddy\n ext4_mb_load_buddy_gfp\n ext4_mb_init_cache\n ext4_read_block_bitmap_nowait\n ext4_wait_block_bitmap\n ext4_validate_block_bitmap\n if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))\n return -EFSCORRUPTED; // There\u0027s no logs.\n if (err)\n return err; // Will return error\next4_lock_group(ac-\u003eac_sb, group);\n if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info))) // Unreachable\n goto out;\n\nAfter commit 9008a58e5dce (\"ext4: make the bitmap read routines return\nreal error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group\nas corrupt on block bitmap error\") is no real solution for allocating\nblocks from corrupted block groups. This is because if\n\u0027EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info)\u0027 is true, then\n\u0027ext4_mb_load_buddy()\u0027 may return an error. This means that the block\nallocation will fail.\nTherefore, check block group if corrupted when ext4_mb_load_buddy()\nreturns error.",
"id": "GHSA-pm4x-jf7f-jmq6",
"modified": "2026-05-21T00:30:26Z",
"published": "2026-05-05T18:33:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43068"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1895f7904be71c48f1e6f338b28f24dabd6b8aeb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46066e3a06647c5b186cc6334409722622d05c44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9370207b36d26e45a8c8ef0500706d37036edd6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6d"
}
],
"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-PM64-F9FF-XC6W
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-14 18:31In the Linux kernel, the following vulnerability has been resolved:
isofs: avoid memory leak in iocharset
A memleak was found as below:
unreferenced object 0xffff0000d10164d8 (size 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [] kmemleak_alloc+0xb8/0xc8 [] __kmalloc_node_track_caller_noprof+0x380/0x474 [] kstrdup+0x70/0xfc [] isofs_parse_param+0x228/0x2c0 [isofs] [] vfs_parse_fs_param+0xf4/0x164 [] vfs_parse_fs_string+0x8c/0xd4 [] vfs_parse_monolithic_sep+0xb0/0xfc [] generic_parse_monolithic+0x30/0x3c [] parse_monolithic_mount_data+0x40/0x4c [] path_mount+0x6c4/0x9ec [] do_mount+0xac/0xc4 [] __arm64_sys_mount+0x16c/0x2b0 [] invoke_syscall+0x7c/0x104 [] el0_svc_common.constprop.1+0xe0/0x104 [] do_el0_svc+0x2c/0x38 [] el0_svc+0x3c/0x1b8
The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function.
For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak.
Let's move the memory freeing of opt->iocharset into isofs_free_fc function.
{
"affected": [],
"aliases": [
"CVE-2024-56534"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nisofs: avoid memory leak in iocharset\n\nA memleak was found as below:\n\nunreferenced object 0xffff0000d10164d8 (size 8):\n comm \"pool-udisksd\", pid 108217, jiffies 4295408555\n hex dump (first 8 bytes):\n 75 74 66 38 00 cc cc cc utf8....\n backtrace (crc de430d31):\n [\u003cffff800081046e6c\u003e] kmemleak_alloc+0xb8/0xc8\n [\u003cffff8000803e6c3c\u003e] __kmalloc_node_track_caller_noprof+0x380/0x474\n [\u003cffff800080363b74\u003e] kstrdup+0x70/0xfc\n [\u003cffff80007bb3c6a4\u003e] isofs_parse_param+0x228/0x2c0 [isofs]\n [\u003cffff8000804d7f68\u003e] vfs_parse_fs_param+0xf4/0x164\n [\u003cffff8000804d8064\u003e] vfs_parse_fs_string+0x8c/0xd4\n [\u003cffff8000804d815c\u003e] vfs_parse_monolithic_sep+0xb0/0xfc\n [\u003cffff8000804d81d8\u003e] generic_parse_monolithic+0x30/0x3c\n [\u003cffff8000804d8bfc\u003e] parse_monolithic_mount_data+0x40/0x4c\n [\u003cffff8000804b6a64\u003e] path_mount+0x6c4/0x9ec\n [\u003cffff8000804b6e38\u003e] do_mount+0xac/0xc4\n [\u003cffff8000804b7494\u003e] __arm64_sys_mount+0x16c/0x2b0\n [\u003cffff80008002b8dc\u003e] invoke_syscall+0x7c/0x104\n [\u003cffff80008002ba44\u003e] el0_svc_common.constprop.1+0xe0/0x104\n [\u003cffff80008002ba94\u003e] do_el0_svc+0x2c/0x38\n [\u003cffff800081041108\u003e] el0_svc+0x3c/0x1b8\n\nThe opt-\u003eiocharset is freed inside the isofs_fill_super function,\nBut there may be situations where it\u0027s not possible to\nenter this function.\n\nFor example, in the get_tree_bdev_flags function,when\nencountering the situation where \"Can\u0027t mount, would change RO state,\"\nIn such a case, isofs_fill_super will not have the opportunity\nto be called,which means that opt-\u003eiocharset will not have the chance\nto be freed,ultimately leading to a memory leak.\n\nLet\u0027s move the memory freeing of opt-\u003eiocharset into\nisofs_free_fc function.",
"id": "GHSA-pm64-f9ff-xc6w",
"modified": "2025-01-14T18:31:54Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b5bbeee4de616a268db77e2f40f19ab010a367b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fbab266ca8000333c966f5b58cb9b9cac658573"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34f090ddb3630a26e5a6b220bf3bfaf5c7b70393"
}
],
"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-PM73-PR98-FPFG
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()
Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().
{
"affected": [],
"aliases": [
"CVE-2026-23087"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: xen: scsiback: Fix potential memory leak in scsiback_remove()\n\nMemory allocated for struct vscsiblk_info in scsiback_probe() is not\nfreed in scsiback_remove() leading to potential memory leaks on remove,\nas well as in the scsiback_probe() error paths. Fix that by freeing it\nin scsiback_remove().",
"id": "GHSA-pm73-pr98-fpfg",
"modified": "2026-07-14T15:31:39Z",
"published": "2026-02-04T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23087"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24c441f0e24da175d7912095663f526ac480dc4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32e52b56056daf0f0881fd9254706acf25b4be97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/427b0fb30ddec3bad05dcd73b00718f98c7026d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a975c72429b050c234405668b742cdecc11548e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/901a5f309daba412e2a30364d7ec1492fa11c32c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8bb3ec8d85951a56af0a72d93ccbc2aee42eef9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f86264ec0e2b102fcd49bf3e4f32fee669d482fc"
}
],
"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-PM77-QRWM-74J5
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-17 18:30In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix memory leak inside XPD_TX with mergeable
When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp".
{
"affected": [],
"aliases": [
"CVE-2022-50065"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: fix memory leak inside XPD_TX with mergeable\n\nWhen we call xdp_convert_buff_to_frame() to get xdpf, if it returns\nNULL, we should check if xdp_page was allocated by xdp_linearize_page().\nIf it is newly allocated, it should be freed here alone. Just like any\nother \"goto err_xdp\".",
"id": "GHSA-pm77-qrwm-74j5",
"modified": "2025-11-17T18:30:23Z",
"published": "2025-06-18T12:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18e383afbd7047af7b055df6e25436e0ce28f8a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a542bee27c6a57e45c33cbbdc963325fd6493af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3723eab11196475ef83279571b2b0bd0924cf82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/faafa2a87f697ee537c29446097e1cc3143506fa"
}
],
"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-PM95-MC7J-6JM3
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-10 18:30In the Linux kernel, the following vulnerability has been resolved:
USB: chipidea: 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.
{
"affected": [],
"aliases": [
"CVE-2023-53334"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: chipidea: 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-pm95-mc7j-6jm3",
"modified": "2025-12-10T18:30:21Z",
"published": "2025-09-16T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4322661af6d7a586a5798ab9aa443f49895b6943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/610373dd354f3d393aa3bdcab59f55024c16b5e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/972e0682f6e3ee6ecf002657df4aaa511d51dd6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff35f3ea3baba5b81416ac02d005cfbf6dd182fa"
}
],
"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.