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-92CR-JQQ3-99X4
Vulnerability from github – Published: 2024-08-22 06:30 – Updated: 2024-08-23 03:30In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memory leak during stateful obj update
stateful objects can be updated from the control plane. The transaction logic allocates a temporary object for this purpose.
The ->init function was called for this object, so plain kfree() leaks resources. We must call ->destroy function of the object.
nft_obj_destroy does this, but it also decrements the module refcount, but the update path doesn't increment it.
To avoid special-casing the update object release, do module_get for the update case too and release it via nft_obj_destroy().
{
"affected": [],
"aliases": [
"CVE-2022-48933"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T04:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix memory leak during stateful obj update\n\nstateful objects can be updated from the control plane.\nThe transaction logic allocates a temporary object for this purpose.\n\nThe -\u003einit function was called for this object, so plain kfree() leaks\nresources. We must call -\u003edestroy function of the object.\n\nnft_obj_destroy does this, but it also decrements the module refcount,\nbut the update path doesn\u0027t increment it.\n\nTo avoid special-casing the update object release, do module_get for\nthe update case too and release it via nft_obj_destroy().",
"id": "GHSA-92cr-jqq3-99x4",
"modified": "2024-08-23T03:30:59Z",
"published": "2024-08-22T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48933"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34bb90e407e3288f610558beaae54ecaa32b11c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53026346a94c43f35c32b18804041bc483271d87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9880e81d3fd6a43c202f205717485290432826"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dad3bdeef45f81a6e90204bcc85360bb76eccec7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e96e204ee6fa46702f6c94c3c69a09e69e0eac52"
}
],
"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-92M7-RR4R-78CQ
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak on spufs_new_file() failure
It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.
{
"affected": [],
"aliases": [
"CVE-2025-22073"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:01Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt\u0027s called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure. That does remove everything\nwe\u0027d managed to create, but... the problem dentry is still\nnegative. IOW, it needs to be explicitly dropped.",
"id": "GHSA-92m7-rr4r-78cq",
"modified": "2025-11-03T21:33:36Z",
"published": "2025-04-16T15:34:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bd56e4e72c354b65c0a7e5ac1c09eca81949d5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/132925bd6772d7614340fb755ac5415462ac8edd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35f789ccebd69f6f9a1e0a9b85435003b2450065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53b189651c33b5f1fb3b755e6a37a8206978514e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90d1b276d1b1379d20ad27d1f6349ba9f44a2e00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96de7fbdc2dcadeebc17c3cb89e7cdab487bfce0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1eef06d10c1a9848e3a762919bbbe315a0a7cb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1ca8698ca1332625d83ea0d753747be66f9906d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d791985ceeb081155b4e96d314ca54c7605dcbe0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-92XW-VWGC-8994
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39A vulnerability in the IPv4 protocol handling of Cisco StarOS could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to a memory leak that occurs during packet processing. An attacker could exploit this vulnerability by sending a series of crafted IPv4 packets through an affected device. A successful exploit could allow the attacker to exhaust the available memory and cause an unexpected restart of the npusim process, leading to a DoS condition on the affected device.
{
"affected": [],
"aliases": [
"CVE-2021-1353"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-20T20:15:00Z",
"severity": "HIGH"
},
"details": "\n A vulnerability in the IPv4 protocol handling of Cisco StarOS could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n The vulnerability is due to a memory leak that occurs during packet processing. An attacker could exploit this vulnerability by sending a series of crafted IPv4 packets through an affected device. A successful exploit could allow the attacker to exhaust the available memory and cause an unexpected restart of the npusim process, leading to a DoS condition on the affected device.\n ",
"id": "GHSA-92xw-vwgc-8994",
"modified": "2022-05-24T17:39:41Z",
"published": "2022-05-24T17:39:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1353"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asr-mem-leak-dos-MTWGHKk3"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-933F-4H29-GQ7R
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 00:30In the Linux kernel, the following vulnerability has been resolved:
perf trace: Really free the evsel->priv area
In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in evsel->priv") it only was freeing if strcmp(evsel->tp_format->system, "syscalls") returned zero, while the corresponding initialization of evsel->priv was being performed if it was not zero, i.e. if the tp system wasn't 'syscalls'.
Just stop looking for that and free it if evsel->priv was set, which should be equivalent.
Also use the pre-existing evsel_trace__delete() function.
This resolves these leaks, detected with:
$ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin
================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]#
With this we plug all leaks with "perf trace sleep 1".
{
"affected": [],
"aliases": [
"CVE-2023-53649"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf trace: Really free the evsel-\u003epriv area\n\nIn 3cb4d5e00e037c70 (\"perf trace: Free syscall tp fields in\nevsel-\u003epriv\") it only was freeing if strcmp(evsel-\u003etp_format-\u003esystem,\n\"syscalls\") returned zero, while the corresponding initialization of\nevsel-\u003epriv was being performed if it was _not_ zero, i.e. if the tp\nsystem wasn\u0027t \u0027syscalls\u0027.\n\nJust stop looking for that and free it if evsel-\u003epriv was set, which\nshould be equivalent.\n\nAlso use the pre-existing evsel_trace__delete() function.\n\nThis resolves these leaks, detected with:\n\n $ make EXTRA_CFLAGS=\"-fsanitize=address\" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin\n\n =================================================================\n ==481565==ERROR: LeakSanitizer: detected memory leaks\n\n Direct leak of 40 byte(s) in 1 object(s) allocated from:\n #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212\n #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n Direct leak of 40 byte(s) in 1 object(s) allocated from:\n #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205\n #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).\n [root@quaco ~]#\n\nWith this we plug all leaks with \"perf trace sleep 1\".",
"id": "GHSA-933f-4h29-gq7r",
"modified": "2026-02-04T00:30:27Z",
"published": "2025-10-07T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53649"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27f396f64537b1ae48d0644d7cbf0d250b3c0b33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62dd514c34be63d3d5cae1f52a7e8b96c6dd6630"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7962ef13651a9163f07b530607392ea123482e8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3bc668581e71e7c3bc7eb1d647f25f8db222163"
}
],
"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-935C-5V3P-3RP4
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-17 18:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix the inode leak in btrfs_iget()
[BUG] There is a bug report that a syzbot reproducer can lead to the following busy inode at unmount time:
BTRFS info (device loop1): last unmount of filesystem 1680000e-3c1e-4c46-84b6-56bd3909af50 VFS: Busy inodes after unmount of loop1 (btrfs) ------------[ cut here ]------------ kernel BUG at fs/super.c:650! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650 Call Trace: kill_anon_super+0x3a/0x60 fs/super.c:1237 btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099 deactivate_locked_super+0xbe/0x1a0 fs/super.c:473 deactivate_super fs/super.c:506 [inline] deactivate_super+0xe2/0x100 fs/super.c:502 cleanup_mnt+0x21f/0x440 fs/namespace.c:1435 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218 do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[CAUSE] When btrfs_alloc_path() failed, btrfs_iget() directly returned without releasing the inode already allocated by btrfs_iget_locked().
This results the above busy inode and trigger the kernel BUG.
[FIX] Fix it by calling iget_failed() if btrfs_alloc_path() failed.
If we hit error inside btrfs_read_locked_inode(), it will properly call iget_failed(), so nothing to worry about.
Although the iget_failed() cleanup inside btrfs_read_locked_inode() is a break of the normal error handling scheme, let's fix the obvious bug and backport first, then rework the error handling later.
{
"affected": [],
"aliases": [
"CVE-2025-37904"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix the inode leak in btrfs_iget()\n\n[BUG]\nThere is a bug report that a syzbot reproducer can lead to the following\nbusy inode at unmount time:\n\n BTRFS info (device loop1): last unmount of filesystem 1680000e-3c1e-4c46-84b6-56bd3909af50\n VFS: Busy inodes after unmount of loop1 (btrfs)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:650!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full)\n Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650\n Call Trace:\n \u003cTASK\u003e\n kill_anon_super+0x3a/0x60 fs/super.c:1237\n btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099\n deactivate_locked_super+0xbe/0x1a0 fs/super.c:473\n deactivate_super fs/super.c:506 [inline]\n deactivate_super+0xe2/0x100 fs/super.c:502\n cleanup_mnt+0x21f/0x440 fs/namespace.c:1435\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:114 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218\n do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u003c/TASK\u003e\n\n[CAUSE]\nWhen btrfs_alloc_path() failed, btrfs_iget() directly returned without\nreleasing the inode already allocated by btrfs_iget_locked().\n\nThis results the above busy inode and trigger the kernel BUG.\n\n[FIX]\nFix it by calling iget_failed() if btrfs_alloc_path() failed.\n\nIf we hit error inside btrfs_read_locked_inode(), it will properly call\niget_failed(), so nothing to worry about.\n\nAlthough the iget_failed() cleanup inside btrfs_read_locked_inode() is a\nbreak of the normal error handling scheme, let\u0027s fix the obvious bug\nand backport first, then rework the error handling later.",
"id": "GHSA-935c-5v3p-3rp4",
"modified": "2025-11-17T18:30:22Z",
"published": "2025-05-20T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37904"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30a339bece3a44ab0a821477139e84fb86af9761"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48c1d1bb525b1c44b8bdc8e7ec5629cb6c2b9fc4"
}
],
"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-936G-6JG3-MGP5
Vulnerability from github – Published: 2024-11-07 12:30 – Updated: 2024-11-22 21:32In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve param->string when parsing mount options
In bpf_parse_param(), keep the value of param->string intact so it can be freed later. Otherwise, the kmalloc area pointed to by param->string will be leaked as shown below:
unreferenced object 0xffff888118c46d20 (size 8): comm "new_name", pid 12109, jiffies 4295580214 hex dump (first 8 bytes): 61 6e 79 00 38 c9 5c 7e any.8.\~ backtrace (crc e1b7f876): [<00000000c6848ac7>] kmemleak_alloc+0x4b/0x80 [<00000000de9f7d00>] __kmalloc_node_track_caller_noprof+0x36e/0x4a0 [<000000003e29b886>] memdup_user+0x32/0xa0 [<0000000007248326>] strndup_user+0x46/0x60 [<0000000035b3dd29>] __x64_sys_fsconfig+0x368/0x3d0 [<0000000018657927>] x64_sys_call+0xff/0x9f0 [<00000000c0cabc95>] do_syscall_64+0x3b/0xc0 [<000000002f331597>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
{
"affected": [],
"aliases": [
"CVE-2024-50165"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-07T10:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Preserve param-\u003estring when parsing mount options\n\nIn bpf_parse_param(), keep the value of param-\u003estring intact so it can\nbe freed later. Otherwise, the kmalloc area pointed to by param-\u003estring\nwill be leaked as shown below:\n\nunreferenced object 0xffff888118c46d20 (size 8):\n comm \"new_name\", pid 12109, jiffies 4295580214\n hex dump (first 8 bytes):\n 61 6e 79 00 38 c9 5c 7e any.8.\\~\n backtrace (crc e1b7f876):\n [\u003c00000000c6848ac7\u003e] kmemleak_alloc+0x4b/0x80\n [\u003c00000000de9f7d00\u003e] __kmalloc_node_track_caller_noprof+0x36e/0x4a0\n [\u003c000000003e29b886\u003e] memdup_user+0x32/0xa0\n [\u003c0000000007248326\u003e] strndup_user+0x46/0x60\n [\u003c0000000035b3dd29\u003e] __x64_sys_fsconfig+0x368/0x3d0\n [\u003c0000000018657927\u003e] x64_sys_call+0xff/0x9f0\n [\u003c00000000c0cabc95\u003e] do_syscall_64+0x3b/0xc0\n [\u003c000000002f331597\u003e] entry_SYSCALL_64_after_hwframe+0x4b/0x53",
"id": "GHSA-936g-6jg3-mgp5",
"modified": "2024-11-22T21:32:12Z",
"published": "2024-11-07T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f97c03f43fadc407de5b5cb01c07755053e1c22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d7a0a426540319327309035509cb768a2f5c2c4"
}
],
"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-938G-XVPF-6653
Vulnerability from github – Published: 2024-07-11 18:31 – Updated: 2025-09-04 03:30A Missing Release of Memory after Effective Lifetime vulnerability in the rtlogd process of Juniper Networks Junos OS on MX Series with SPC3 allows an unauthenticated, adjacent attacker to trigger internal events cause ( which can be done by repeated port flaps) to cause a slow memory leak, ultimately leading to a Denial of Service (DoS).
Memory can only be recovered by manually restarting rtlogd process. The memory usage can be monitored using the below command.
????user@host> show system processes extensive | match rtlog
This issue affects Junos OS on MX Series with SPC3 line card:
- from 21.2R3 before 21.2R3-S8,
- from 21.4R2 before 21.4R3-S6,
- from 22.1 before 22.1R3-S5,
- from 22.2 before 22.2R3-S3,
- from 22.3 before 22.3R3-S2,
- from 22.4 before 22.4R3-S1,
- from 23.2 before 23.2R2,
- from 23.4 before 23.4R2.
{
"affected": [],
"aliases": [
"CVE-2024-39550"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-11T17:15:15Z",
"severity": "HIGH"
},
"details": "A Missing Release of Memory after Effective Lifetime vulnerability in the rtlogd process\u00a0of Juniper Networks Junos OS on MX Series with SPC3 allows an unauthenticated, adjacent attacker to trigger internal events cause ( which can be done by repeated port flaps)\u00a0to cause a slow memory leak, ultimately leading to a Denial of Service (DoS). \n\nMemory can only be recovered by manually restarting rtlogd process.\u00a0\nThe memory usage can be monitored using the below command.\n\n????user@host\u003e show system processes extensive | match rtlog\u00a0\n\n\n\nThis issue affects Junos OS on MX Series with SPC3 line card:\u00a0\n\n\n\n * from 21.2R3 before 21.2R3-S8,\u00a0\n * from 21.4R2 before 21.4R3-S6,\u00a0\n * from 22.1 before 22.1R3-S5,\u00a0\n * from 22.2 before 22.2R3-S3,\u00a0\n * from 22.3 before 22.3R3-S2,\u00a0\n * from 22.4 before 22.4R3-S1,\u00a0\n * from 23.2 before 23.2R2,\u00a0\n * from 23.4 before 23.4R2.",
"id": "GHSA-938g-xvpf-6653",
"modified": "2025-09-04T03:30:33Z",
"published": "2024-07-11T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39550"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA83012"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/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:U/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-945J-P452-JCMX
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-26 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix chunk map leak in btrfs_map_block() after btrfs_chunk_map_num_copies()
Fix a chunk map leak in btrfs_map_block(): if we return early with -EINVAL, we're not freeing the chunk map that we've just looked up.
{
"affected": [],
"aliases": [
"CVE-2026-43393"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix chunk map leak in btrfs_map_block() after btrfs_chunk_map_num_copies()\n\nFix a chunk map leak in btrfs_map_block(): if we return early with -EINVAL,\nwe\u0027re not freeing the chunk map that we\u0027ve just looked up.",
"id": "GHSA-945j-p452-jcmx",
"modified": "2026-05-26T15:32:08Z",
"published": "2026-05-08T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e4aaf5a3212b6a469c2489637c29a8e2a5062a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f90c5c2698383984102401b1724b0b67da832ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bdf00ed75c477252578068dba19934cd825f20a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f15fb3d41543244d1179f423da4a4832a55bc050"
}
],
"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-948P-87WR-RW9M
Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-23 12:00In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization.
{
"affected": [],
"aliases": [
"CVE-2022-41624"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-19T22:15:00Z",
"severity": "HIGH"
},
"details": "In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization.",
"id": "GHSA-948p-87wr-rw9m",
"modified": "2022-10-23T12:00:26Z",
"published": "2022-10-20T12:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41624"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K43024307"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-94C2-F29F-CQQQ
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 21:31In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
If ret_val is non-zero, then free the iocbq request structure.
{
"affected": [],
"aliases": [
"CVE-2022-50027"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix possible memory leak when failing to issue CMF WQE\n\nThere is no corresponding free routine if lpfc_sli4_issue_wqe fails to\nissue the CMF WQE in lpfc_issue_cmf_sync_wqe.\n\nIf ret_val is non-zero, then free the iocbq request structure.",
"id": "GHSA-94c2-f29f-cqqq",
"modified": "2025-11-13T21:31:17Z",
"published": "2025-06-18T12:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50027"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f67dc7970bce3529edce93a0a14234d88b3fcd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4eb7a1beff03836d3df271cd23b790884e3facb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c8e2e607270a368834a0ef72aa82d970f89c596"
}
],
"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.