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-JCX4-9C43-7HHG
Vulnerability from github – Published: 2022-11-29 06:30 – Updated: 2022-12-01 21:30GPAC v2.1-DEV-rev428-gcb8ae46c8-master was discovered to contain a memory leak via the function dimC_box_read at isomedia/box_code_3gpp.c.
{
"affected": [],
"aliases": [
"CVE-2022-45204"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-29T04:15:00Z",
"severity": "MODERATE"
},
"details": "GPAC v2.1-DEV-rev428-gcb8ae46c8-master was discovered to contain a memory leak via the function dimC_box_read at isomedia/box_code_3gpp.c.",
"id": "GHSA-jcx4-9c43-7hhg",
"modified": "2022-12-01T21:30:19Z",
"published": "2022-11-29T06:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45204"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/issues/2307"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JCXX-X6VW-F3XQ
Vulnerability from github – Published: 2026-04-03 15:30 – Updated: 2026-04-24 15:32In the Linux kernel, the following vulnerability has been resolved:
drm/xe/reg_sr: Fix leak on xa_store failure
Free the newly allocated entry when xa_store() fails to avoid a memory leak on the error path.
v2: use goto fail_free. (Bala)
(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)
{
"affected": [],
"aliases": [
"CVE-2026-23418"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T14:16:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/reg_sr: Fix leak on xa_store failure\n\nFree the newly allocated entry when xa_store() fails to avoid a memory\nleak on the error path.\n\nv2: use goto fail_free. (Bala)\n\n(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)",
"id": "GHSA-jcxx-x6vw-f3xq",
"modified": "2026-04-24T15:32:20Z",
"published": "2026-04-03T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23418"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/05e3f01974d09d1b746dedf4144f708b5033e76f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3091723785def05ebfe6a50866f87a044ae314ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f461da14c7b226d1c4c179ae69956ccb8e134e2"
}
],
"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-JFRM-9RR7-R45W
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-03 18:30In the Linux kernel, the following vulnerability has been resolved:
ubifs: Free memory for tmpfile name
When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed.
When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'tmpfile' just opening a tmpfile:
unreferenced object 0xffff88810178f380 (size 32): comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename ubifs_tmpfile vfs_tmpfile path_openat
Free this memory after it has been copied to the inode.
{
"affected": [],
"aliases": [
"CVE-2023-53276"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Free memory for tmpfile name\n\nWhen opening a ubifs tmpfile on an encrypted directory, function\nfscrypt_setup_filename allocates memory for the name that is to be\nstored in the directory entry, but after the name has been copied to the\ndirectory entry inode, the memory is not freed.\n\nWhen running kmemleak on it we see that it is registered as a leak. The\nreport below is triggered by a simple program \u0027tmpfile\u0027 just opening a\ntmpfile:\n\n unreferenced object 0xffff88810178f380 (size 32):\n comm \"tmpfile\", pid 509, jiffies 4294934744 (age 1524.742s)\n backtrace:\n __kmem_cache_alloc_node\n __kmalloc\n fscrypt_setup_filename\n ubifs_tmpfile\n vfs_tmpfile\n path_openat\n\nFree this memory after it has been copied to the inode.",
"id": "GHSA-jfrm-9rr7-r45w",
"modified": "2025-12-03T18:30:20Z",
"published": "2025-09-16T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53276"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/107d481642c356a5668058066360fc473911e628"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e43d4284bdc3bd34bd770fea13910ac37ab0618"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29738e1bcc799dd754711d4e4aab967f0c018175"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/823f554747f8aafaa965fb2f3ae794110ed429ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ad8c67a897e68426e85990ebfe0a7d1f71fc79f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8f444a4fadfb5070ed7e298e0a5ceb4a18014f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce840284929b75dbbf062e0ce7fcb78a63b08b5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd197308c0e4f738c7ea687d5332035c5753881c"
}
],
"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-JFW6-W783-5HHM
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix memory leaks of napi_get_frags
kmemleak reports after running test_progs:
unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks
To fix, add napi_complete() after napi_gro_frags().
{
"affected": [],
"aliases": [
"CVE-2022-49871"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix memory leaks of napi_get_frags\n\nkmemleak reports after running test_progs:\n\nunreferenced object 0xffff8881b1672dc0 (size 232):\n comm \"test_progs\", pid 394388, jiffies 4354712116 (age 841.975s)\n hex dump (first 32 bytes):\n e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g.....\n 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............\n backtrace:\n [\u003c00000000c8f01748\u003e] napi_skb_cache_get+0xd4/0x150\n [\u003c0000000041c7fc09\u003e] __napi_build_skb+0x15/0x50\n [\u003c00000000431c7079\u003e] __napi_alloc_skb+0x26e/0x540\n [\u003c000000003ecfa30e\u003e] napi_get_frags+0x59/0x140\n [\u003c0000000099b2199e\u003e] tun_get_user+0x183d/0x3bb0 [tun]\n [\u003c000000008a5adef0\u003e] tun_chr_write_iter+0xc0/0x1b1 [tun]\n [\u003c0000000049993ff4\u003e] do_iter_readv_writev+0x19f/0x320\n [\u003c000000008f338ea2\u003e] do_iter_write+0x135/0x630\n [\u003c000000008a3377a4\u003e] vfs_writev+0x12e/0x440\n [\u003c00000000a6b5639a\u003e] do_writev+0x104/0x280\n [\u003c00000000ccf065d8\u003e] do_syscall_64+0x3b/0x90\n [\u003c00000000d776e329\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\ntun_get_user()\n napi_gro_frags()\n napi_frags_finish()\n case GRO_NORMAL:\n gro_normal_one()\n list_add_tail(\u0026skb-\u003elist, \u0026napi-\u003erx_list);\n \u003c-- While napi-\u003erx_count \u003c READ_ONCE(gro_normal_batch),\n \u003c-- gro_normal_list() is not called, napi-\u003erx_list is not empty\n \u003c-- not ask to complete the gro work, will cause memory leaks in\n \u003c-- following tun_napi_del()\n...\ntun_napi_del()\n netif_napi_del()\n __netif_napi_del()\n \u003c-- \u0026napi-\u003erx_list is not empty, which caused memory leaks\n\nTo fix, add napi_complete() after napi_gro_frags().",
"id": "GHSA-jfw6-w783-5hhm",
"modified": "2025-05-07T15:31:25Z",
"published": "2025-05-01T15:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49871"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb"
}
],
"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-JFXC-PHGJ-XGP4
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 21:31In the Linux kernel, the following vulnerability has been resolved:
net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()
The issue happens on some error handling paths. When the function
fails to grab the object xprt, it simply returns 0, forgetting to
decrease the reference count of another object xps, which is
increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount
leaks. Also, the function forgets to check whether xps is valid
before using it, which may result in NULL-dereferencing issues.
Fix it by adding proper error handling code when either xprt or
xps is NULL.
{
"affected": [],
"aliases": [
"CVE-2022-50046"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()\n\nThe issue happens on some error handling paths. When the function\nfails to grab the object `xprt`, it simply returns 0, forgetting to\ndecrease the reference count of another object `xps`, which is\nincreased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount\nleaks. Also, the function forgets to check whether `xps` is valid\nbefore using it, which may result in NULL-dereferencing issues.\n\nFix it by adding proper error handling code when either `xprt` or\n`xps` is NULL.",
"id": "GHSA-jfxc-phgj-xgp4",
"modified": "2025-11-13T21:31:18Z",
"published": "2025-06-18T12:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50046"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76fbeb1662b1c56514325118a07fba74dc4c79fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfc48f1b0505ffcb03a6d749139b7577d6b81ae0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0434f0e058648649250b8ed6078b66d773de723"
}
],
"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-JG34-CMW8-GW85
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2024-11-07 18:31In the Linux kernel, the following vulnerability has been resolved:
xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
int type = nla_type(nla);
if (type > XFRMA_MAX) { return -EOPNOTSUPP; }
@type is then used as an array index and can be used as a Spectre v1 gadget.
if (nla_len(nla) < compat_policy[type].len) {
array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users.
{
"affected": [],
"aliases": [
"CVE-2023-52746"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:14Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()\n\n int type = nla_type(nla);\n\n if (type \u003e XFRMA_MAX) {\n return -EOPNOTSUPP;\n }\n\n@type is then used as an array index and can be used\nas a Spectre v1 gadget.\n\n if (nla_len(nla) \u003c compat_policy[type].len) {\n\narray_index_nospec() can be used to prevent leaking\ncontent of kernel memory to malicious users.",
"id": "GHSA-jg34-cmw8-gw85",
"modified": "2024-11-07T18:31:20Z",
"published": "2024-05-21T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52746"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JG3V-4F9W-62X2
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-02 21:31In the Linux kernel, the following vulnerability has been resolved:
nfc: fix memory leak of se_io context in nfc_genl_se_io
The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked.
The patch proposes to free the cb_context explicitly on those error paths.
At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not.
{
"affected": [],
"aliases": [
"CVE-2023-53298"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fix memory leak of se_io context in nfc_genl_se_io\n\nThe callback context for sending/receiving APDUs to/from the selected\nsecure element is allocated inside nfc_genl_se_io and supposed to be\neventually freed in se_io_cb callback function. However, there are several\nerror paths where the bwi_timer is not charged to call se_io_cb later, and\nthe cb_context is leaked.\n\nThe patch proposes to free the cb_context explicitly on those error paths.\n\nAt the moment we can\u0027t simply check \u0027dev-\u003eops-\u003ese_io()\u0027 return value as it\nmay be negative in both cases: when the timer was charged and was not.",
"id": "GHSA-jg3v-4f9w-62x2",
"modified": "2025-12-02T21:31:26Z",
"published": "2025-09-16T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53298"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/271eed1736426103335c5aac50f15b0f4d236bc0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5321da6d84b87a34eea441677d649c34bd854169"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8978315cb4bf8878c9c8ec05dafd8f7ff539860d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af452e35b9e6a87cd49e54a7a3d60d934b194651"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2036a252381949d3b743a3de069324ae3028a57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba98db08895748c12e5ded52cd1598dce2c79e55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c494365432dcdc549986f4d9af9eb6190cbdb153"
}
],
"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-JG7C-PX6J-W73V
Vulnerability from github – Published: 2022-05-13 01:10 – Updated: 2022-05-13 01:10In ImageMagick before 7.0.8-25, a memory leak exists in ReadSIXELImage in coders/sixel.c.
{
"affected": [],
"aliases": [
"CVE-2019-7396"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-05T00:29:00Z",
"severity": "HIGH"
},
"details": "In ImageMagick before 7.0.8-25, a memory leak exists in ReadSIXELImage in coders/sixel.c.",
"id": "GHSA-jg7c-px6j-w73v",
"modified": "2022-05-13T01:10:29Z",
"published": "2022-05-13T01:10:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7396"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/1452"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/748a03651e5b138bcaf160d15133de2f4b1b89ce"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4034-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4712"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00034.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106849"
}
],
"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-JG9P-QRJ8-5JW6
Vulnerability from github – Published: 2025-04-14 18:31 – Updated: 2025-04-14 18:31In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report:
unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [] __kmalloc+0x613/0x910 [] jffs2_sum_add_dirent_mem+0x5c/0xa0 [] jffs2_scan_medium.cold+0x36e5/0x4794 [] jffs2_do_mount_fs.cold+0xa7/0x2267 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [] mtd_get_sb+0x254/0x400 [] mtd_get_sb_by_nr+0x4f/0xd0 [] get_tree_mtd+0x498/0x840 [] jffs2_get_tree+0x25/0x30 [] vfs_get_tree+0x8d/0x2e0 [] path_mount+0x50f/0x1e50 [] do_mount+0x107/0x130 [] __se_sys_mount+0x1c5/0x2f0 [] __x64_sys_mount+0xc7/0x160 [] do_syscall_64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_inode_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xattr_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xref_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x3a20/0x4794 [...]
Therefore, we should call jffs2_sum_reset_collected(s) on exit to release the memory added in s. In addition, a new tag "out_buf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis)
{
"affected": [],
"aliases": [
"CVE-2022-49276"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_scan_medium\n\nIf an error is returned in jffs2_scan_eraseblock() and some memory\nhas been added to the jffs2_summary *s, we can observe the following\nkmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88812b889c40 (size 64):\n comm \"mount\", pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.\n 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................\n backtrace:\n [\u003cffffffffae93a3a3\u003e] __kmalloc+0x613/0x910\n [\u003cffffffffaf423b9c\u003e] jffs2_sum_add_dirent_mem+0x5c/0xa0\n [\u003cffffffffb0f3afa8\u003e] jffs2_scan_medium.cold+0x36e5/0x4794\n [\u003cffffffffb0f3dbe1\u003e] jffs2_do_mount_fs.cold+0xa7/0x2267\n [\u003cffffffffaf40acf3\u003e] jffs2_do_fill_super+0x383/0xc30\n [\u003cffffffffaf40c00a\u003e] jffs2_fill_super+0x2ea/0x4c0\n [\u003cffffffffb0315d64\u003e] mtd_get_sb+0x254/0x400\n [\u003cffffffffb0315f5f\u003e] mtd_get_sb_by_nr+0x4f/0xd0\n [\u003cffffffffb0316478\u003e] get_tree_mtd+0x498/0x840\n [\u003cffffffffaf40bd15\u003e] jffs2_get_tree+0x25/0x30\n [\u003cffffffffae9f358d\u003e] vfs_get_tree+0x8d/0x2e0\n [\u003cffffffffaea7a98f\u003e] path_mount+0x50f/0x1e50\n [\u003cffffffffaea7c3d7\u003e] do_mount+0x107/0x130\n [\u003cffffffffaea7c5c5\u003e] __se_sys_mount+0x1c5/0x2f0\n [\u003cffffffffaea7c917\u003e] __x64_sys_mount+0xc7/0x160\n [\u003cffffffffb10142f5\u003e] do_syscall_64+0x45/0x70\nunreferenced object 0xffff888114b54840 (size 32):\n comm \"mount\", pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............\n 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.\n backtrace:\n [\u003cffffffffae93be24\u003e] kmem_cache_alloc_trace+0x584/0x880\n [\u003cffffffffaf423b04\u003e] jffs2_sum_add_inode_mem+0x54/0x90\n [\u003cffffffffb0f3bd44\u003e] jffs2_scan_medium.cold+0x4481/0x4794\n [...]\nunreferenced object 0xffff888114b57280 (size 32):\n comm \"mount\", pid 692, jiffies 4294838393 (age 34.357s)\n hex dump (first 32 bytes):\n 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............\n 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.\n backtrace:\n [\u003cffffffffae93be24\u003e] kmem_cache_alloc_trace+0x584/0x880\n [\u003cffffffffaf423c34\u003e] jffs2_sum_add_xattr_mem+0x54/0x90\n [\u003cffffffffb0f3a24f\u003e] jffs2_scan_medium.cold+0x298c/0x4794\n [...]\nunreferenced object 0xffff8881116cd510 (size 16):\n comm \"mount\", pid 692, jiffies 4294838395 (age 34.355s)\n hex dump (first 16 bytes):\n 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.\n backtrace:\n [\u003cffffffffae93be24\u003e] kmem_cache_alloc_trace+0x584/0x880\n [\u003cffffffffaf423cc4\u003e] jffs2_sum_add_xref_mem+0x54/0x90\n [\u003cffffffffb0f3b2e3\u003e] jffs2_scan_medium.cold+0x3a20/0x4794\n [...]\n--------------------------------------------\n\nTherefore, we should call jffs2_sum_reset_collected(s) on exit to\nrelease the memory added in s. In addition, a new tag \"out_buf\" is\nadded to prevent the NULL pointer reference caused by s being NULL.\n(thanks to Zhang Yi for this analysis)",
"id": "GHSA-jg9p-qrj8-5jw6",
"modified": "2025-04-14T18:31:48Z",
"published": "2025-04-14T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49276"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/455f4a23490bfcbedc8e5c245c463a59b19e5ddd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51dbb5e36d59f62e34d462b801c1068248149cfe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52ba0ab4f0a606f02a6163493378989faa1ec10a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82462324bf35b6b553400af1c1aa265069cee28f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b0c69182f09b70779817af4dcf89780955d5c4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b26bbc0c122cad038831f226a4cb4de702225e16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b36bccb04e14cc0c1e2d0e92d477fe220314fad6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e711913463af916d777a4873068f415f1fe2ad33"
}
],
"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-JGCM-2G93-RJCX
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2025-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: Fix memory leak
This checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone the skb and also make sure btmtk_process_coredump frees the skb passed following the same logic.
{
"affected": [],
"aliases": [
"CVE-2024-26887"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: Fix memory leak\n\nThis checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone\nthe skb and also make sure btmtk_process_coredump frees the skb passed\nfollowing the same logic.",
"id": "GHSA-jgcm-2g93-rjcx",
"modified": "2025-01-07T18:30:42Z",
"published": "2024-04-17T12:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26887"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/620b9e60e4b55fa55540ce852a0f3c9e6091dbbc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79f4127a502c5905f04da1f20a7bbe07103fb77c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b08bd8f02a24e2b82fece5ac51dc1c3d9aa6c404"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b10e6f6b160a60b98fb7476028f5a95405bbd725"
}
],
"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.