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.
2002 vulnerabilities reference this CWE, most recent first.
GHSA-VV75-456Q-6J78
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-10 21:30In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: fix potential memleak in 'add_widget_node'
As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources.
{
"affected": [],
"aliases": [
"CVE-2022-49835"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix potential memleak in \u0027add_widget_node\u0027\n\nAs \u0027kobject_add\u0027 may allocated memory for \u0027kobject-\u003ename\u0027 when return error.\nAnd in this function, if call \u0027kobject_add\u0027 failed didn\u0027t free kobject.\nSo call \u0027kobject_put\u0027 to recycling resources.",
"id": "GHSA-vv75-456q-6j78",
"modified": "2025-11-10T21:30:28Z",
"published": "2025-05-01T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49835"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02dea987ec1cac712c78e75d224ceb9bb73519ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a79f9568de08657fcdbc41d6fc4c0ca145a7a2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/455d99bd6baf19688048b6d42d9fa74eae27f93b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7140d7aaf93da6a665b454f91bb4dc6b1de218bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90b7d055e2b5f39429f9a9e3815b48a48530ef28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a5523f72bd2b0d66eef3d58810c6eb7b5ffc143"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b688a3ec235222d9a84e43a48a6f31acb95baf2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb0ac8d5e541224f599bc8e8f31a313faa4bf7b7"
}
],
"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-VV89-4Q7P-GWX6
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288
This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN.
Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)
Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open
- Run a program that uses a high file descriptor: #include #include
int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }
- Observe WARNING in dmesg at mm/slub.c:5027
systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:
- The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
- Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
- The resulting allocations (>8GB) are impractical and will always fail
systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.
While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.
Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.
{
"affected": [],
"aliases": [
"CVE-2025-39756"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: \u003e 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n # echo 1073741816 \u003e /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n #include \u003cunistd.h\u003e\n #include \u003csys/resource.h\u003e\n\n int main() {\n struct rlimit rlim = {1073741824, 1073741824};\n setrlimit(RLIMIT_NOFILE, \u0026rlim);\n dup2(2, 1073741880); // Triggers the warning\n return 0;\n }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel\u0027s allocation functions still enforce INT_MAX as a maximum\n size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n inadvertently trigger massive allocations\n3. The resulting allocations (\u003e8GB) are impractical and will always fail\n\nsystemd\u0027s algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical \u003e8GB memory allocation request.",
"id": "GHSA-vv89-4q7p-gwx6",
"modified": "2026-07-14T15:31:27Z",
"published": "2025-09-11T18:35:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39756"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04a2c4b4511d186b0fce685da21085a5d4acd370"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/237e416eb62101f21b28c9e6e564d10efe1ecc6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/628fc28f42d979f36dbf75a6129ac7730e30c04e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/749528086620f8012b83ae032a80f6ffa80c45cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f61fa6a2a89a610120bc4e5d24379c667314b5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4159c5a90c03f8acd3de345a7f5fc63b0909818"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4f9351243c17865a8cdbe6b3ccd09d0b13a7bcc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dfd1f4ea98c3bd3a03d12169b5b2daa1f0a3e4ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f95638a8f22eba307dceddf5aef9ae2326bbcf98"
},
{
"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-VVP4-J3WJ-9JVQ
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memory leaks in __check_func_call
kmemleak reports this issue:
unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 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: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested.
In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state().
{
"affected": [],
"aliases": [
"CVE-2022-49837"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memory leaks in __check_func_call\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff88817139d000 (size 2048):\n comm \"test_progs\", pid 33246, jiffies 4307381979 (age 45851.820s)\n hex dump (first 32 bytes):\n 01 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 [\u003c0000000045f075f0\u003e] kmalloc_trace+0x27/0xa0\n [\u003c0000000098b7c90a\u003e] __check_func_call+0x316/0x1230\n [\u003c00000000b4c3c403\u003e] check_helper_call+0x172e/0x4700\n [\u003c00000000aa3875b7\u003e] do_check+0x21d8/0x45e0\n [\u003c000000001147357b\u003e] do_check_common+0x767/0xaf0\n [\u003c00000000b5a595b4\u003e] bpf_check+0x43e3/0x5bc0\n [\u003c0000000011e391b1\u003e] bpf_prog_load+0xf26/0x1940\n [\u003c0000000007f765c0\u003e] __sys_bpf+0xd2c/0x3650\n [\u003c00000000839815d6\u003e] __x64_sys_bpf+0x75/0xc0\n [\u003c00000000946ee250\u003e] do_syscall_64+0x3b/0x90\n [\u003c0000000000506b7f\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root case here is: In function prepare_func_exit(), the callee is\nnot released in the abnormal scenario after \"state-\u003ecurframe--;\". To\nfix, move \"state-\u003ecurframe--;\" to the very bottom of the function,\nright when we free callee and reset frame[] pointer to NULL, as Andrii\nsuggested.\n\nIn addition, function __check_func_call() has a similar problem. In\nthe abnormal scenario before \"state-\u003ecurframe++;\", the callee also\nshould be released by free_func_state().",
"id": "GHSA-vvp4-j3wj-9jvq",
"modified": "2025-05-07T15:31:24Z",
"published": "2025-05-01T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49837"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83946d772e756734a900ef99dbe0aeda506adf37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4944497827a3d14bc5a26dbcfb7433eb5a956c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb86559a691cea5fa63e57a03ec3dc9c31e97955"
}
],
"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-VVWR-R28W-F48X
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-05 15:31In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()
In rtw_init_cmd_priv(), if pcmdpriv->rsp_allocated_buf is allocated
in failure, then pcmdpriv->cmd_allocated_buf will be not properly
released. Besides, considering there are only two error paths and the
first one can directly return, so we do not need implicitly jump to the
exit tag to execute the error handler.
So this patch added kfree(pcmdpriv->cmd_allocated_buf); on the error
path to release the resource and simplified the return logic of
rtw_init_cmd_priv(). As there is no proper device to test with, no runtime
testing was performed.
{
"affected": [],
"aliases": [
"CVE-2022-50513"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()\n\nIn rtw_init_cmd_priv(), if `pcmdpriv-\u003ersp_allocated_buf` is allocated\nin failure, then `pcmdpriv-\u003ecmd_allocated_buf` will be not properly\nreleased. Besides, considering there are only two error paths and the\nfirst one can directly return, so we do not need implicitly jump to the\n`exit` tag to execute the error handler.\n\nSo this patch added `kfree(pcmdpriv-\u003ecmd_allocated_buf);` on the error\npath to release the resource and simplified the return logic of\nrtw_init_cmd_priv(). As there is no proper device to test with, no runtime\ntesting was performed.",
"id": "GHSA-vvwr-r28w-f48x",
"modified": "2026-02-05T15:31:07Z",
"published": "2025-10-07T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50513"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39bef9c6a91bbb790d04c1347cfeae584541fb6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/708056fba733a73d926772ea4ce9a42d240345da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8db6ca84eee0ac258706f3fca54f7c021cb159ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5d8f05edb36fc4ab15beec62cb6ab62f5a60fe2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6cc39db24a63f68314473621020ed8cad7be423"
}
],
"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-VW67-JHPQ-87PM
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06There is a memory leak vulnerability in Huawei products. A resource management weakness exists in a module. Attackers with high privilege can exploit this vulnerability by performing some operations. This can lead to memory leak. Affected product versions include:IPS Module V500R005C00SPC100,V500R005C00SPC200;NGFW Module V500R005C00SPC100,V500R005C00SPC200;NIP6300 V500R005C00SPC100,V500R005C10SPC200;NIP6600 V500R005C00SPC100,V500R005C00SPC200;Secospace USG6300 V500R005C00SPC100,V500R005C00SPC200;Secospace USG6500 V500R005C00SPC100,V500R005C10SPC200;Secospace USG6600 V500R005C00SPC100,V500R005C00SPC200.
{
"affected": [],
"aliases": [
"CVE-2021-22341"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T20:15:00Z",
"severity": "MODERATE"
},
"details": "There is a memory leak vulnerability in Huawei products. A resource management weakness exists in a module. Attackers with high privilege can exploit this vulnerability by performing some operations. This can lead to memory leak. Affected product versions include:IPS Module V500R005C00SPC100,V500R005C00SPC200;NGFW Module V500R005C00SPC100,V500R005C00SPC200;NIP6300 V500R005C00SPC100,V500R005C10SPC200;NIP6600 V500R005C00SPC100,V500R005C00SPC200;Secospace USG6300 V500R005C00SPC100,V500R005C00SPC200;Secospace USG6500 V500R005C00SPC100,V500R005C10SPC200;Secospace USG6600 V500R005C00SPC100,V500R005C00SPC200.",
"id": "GHSA-vw67-jhpq-87pm",
"modified": "2022-05-24T19:06:28Z",
"published": "2022-05-24T19:06:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22341"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210506-01-memleak-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VW94-38CW-WJ37
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()
Smatch reports: drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe() warn: missing unwind goto?
After geting irq, if ret < 0, it will return without error handling to free memory. Just add error handling to fix this problem.
{
"affected": [],
"aliases": [
"CVE-2023-53379"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()\n\nSmatch reports:\ndrivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()\nwarn: missing unwind goto?\n\nAfter geting irq, if ret \u003c 0, it will return without error handling to\nfree memory.\nJust add error handling to fix this problem.",
"id": "GHSA-vw94-38cw-wj37",
"modified": "2025-12-12T18:30:28Z",
"published": "2025-09-18T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/342161c11403ea00e9febc16baab1d883d589d04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38dbd6f72bfbeba009efe0e9ec1f3ff09f9e23fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e5a7bebf832b1482efe27bcc15a88c5b28a30d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4da9edeccf77d7b4c6dbcb34d5908acdaa5bd7e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56901de563359de20513e16a9ae008ae2c22e9a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd9b7c89a80428cc5f4ae0d2e1311fdedb2a1aac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecf26d6e1b5450620c214feea537bb6ce05c6741"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe9cdc19861950582f077f254a12026e169eaee5"
}
],
"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-VWFW-R6QW-22RW
Vulnerability from github – Published: 2025-02-10 15:32 – Updated: 2025-02-10 15:32A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
{
"affected": [],
"aliases": [
"CVE-2025-1149"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-10T15:15:13Z",
"severity": "LOW"
},
"details": "A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: \"I\u0027m not going to commit some of the leak fixes I\u0027ve been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master.\"",
"id": "GHSA-vwfw-r6qw-22rw",
"modified": "2025-02-10T15:32:22Z",
"published": "2025-02-10T15:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1149"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/attachment.cgi?id=15887"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=32576"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.295053"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.295053"
},
{
"type": "WEB",
"url": "https://www.gnu.org"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/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-VWG7-HHF5-FF3G
Vulnerability from github – Published: 2025-04-18 15:31 – Updated: 2025-11-07 00:30In the Linux kernel, the following vulnerability has been resolved:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.
1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.
3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race
When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.
Background: why UNcorrected errors tied to CMCI in Intel platform [1]
Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UCNA signature name.
Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a speculative read.
2) Core finds it is going to use address A soon after sending the read request
3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).
Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-39989"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-18T07:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \"mm/hwpoison: Fix regressions in memory failure handling\",\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit\u0027s not an urgent problem that no core is on the verge of consuming that\nbad data. It\u0027s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can\u0027t tell the difference\nbetween a \"real\" read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\"mm/hwpoison: fix error page recovered but reported\n\"not\n---truncated---",
"id": "GHSA-vwg7-hhf5-ff3g",
"modified": "2025-11-07T00:30:26Z",
"published": "2025-04-18T15:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39989"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4"
}
],
"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-VWM6-3CGQ-CW2W
Vulnerability from github – Published: 2022-10-21 12:00 – Updated: 2022-10-24 19:00A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-3629"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-404"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-21T06:15:00Z",
"severity": "LOW"
},
"details": "A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability.",
"id": "GHSA-vwm6-3cgq-cw2w",
"modified": "2022-10-24T19:00:17Z",
"published": "2022-10-21T12:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3629"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.211930"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.211930"
}
],
"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-VWV5-298P-PW28
Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-06-30 03:36A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.
{
"affected": [],
"aliases": [
"CVE-2026-3104"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T14:16:36Z",
"severity": "HIGH"
},
"details": "A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain.\nThis issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.\nBIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.",
"id": "GHSA-vwv5-298p-pw28",
"modified": "2026-06-30T03:36:00Z",
"published": "2026-03-25T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3104"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6935"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-3104"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2451310"
},
{
"type": "WEB",
"url": "https://downloads.isc.org/isc/bind9/9.20.21"
},
{
"type": "WEB",
"url": "https://downloads.isc.org/isc/bind9/9.21.20"
},
{
"type": "WEB",
"url": "https://kb.isc.org/docs/cve-2026-3104"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-3104.json"
}
],
"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"
}
]
}
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.