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.
2020 vulnerabilities reference this CWE, most recent first.
GHSA-7RCJ-VMJP-FWMV
Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Fix memory leak problem
This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.
As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is:
In parse_var_defs() if there is a problem allocating var_defs.expr, the earlier var_defs.name is freed. This free is duplicated by free_var_defs() which frees the rest of the list.
However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed;
IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
\
|
0th 1th (N-1)-th N-th V
+-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------
These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed.
If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
{
"affected": [],
"aliases": [
"CVE-2022-49648"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Fix memory leak problem\n\nThis reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.\n\nAs commit 46bbe5c671e0 (\"tracing: fix double free\") said, the\n\"double free\" problem reported by clang static analyzer is:\n \u003e In parse_var_defs() if there is a problem allocating\n \u003e var_defs.expr, the earlier var_defs.name is freed.\n \u003e This free is duplicated by free_var_defs() which frees\n \u003e the rest of the list.\n\nHowever, if there is a problem allocating N-th var_defs.expr:\n + in parse_var_defs(), the freed \u0027earlier var_defs.name\u0027 is\n actually the N-th var_defs.name;\n + then in free_var_defs(), the names from 0th to (N-1)-th are freed;\n\n IF ALLOCATING PROBLEM HAPPENED HERE!!! -+\n \\\n |\n 0th 1th (N-1)-th N-th V\n +-------------+-------------+-----+-------------+-----------\nvar_defs: | name | expr | name | expr | ... | name | expr | name | ///\n +-------------+-------------+-----+-------------+-----------\n\nThese two frees don\u0027t act on same name, so there was no \"double free\"\nproblem before. Conversely, after that commit, we get a \"memory leak\"\nproblem because the above \"N-th var_defs.name\" is not freed.\n\nIf enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th\nvar_defs.expr allocated, then execute on shell like:\n $ echo \u0027hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc\u0027 \u003e \\\n/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger\n\nThen kmemleak reports:\n unreferenced object 0xffff8fb100ef3518 (size 8):\n comm \"bash\", pid 196, jiffies 4295681690 (age 28.538s)\n hex dump (first 8 bytes):\n 76 31 00 00 b1 8f ff ff v1......\n backtrace:\n [\u003c0000000038fe4895\u003e] kstrdup+0x2d/0x60\n [\u003c00000000c99c049a\u003e] event_hist_trigger_parse+0x206f/0x20e0\n [\u003c00000000ae70d2cc\u003e] trigger_process_regex+0xc0/0x110\n [\u003c0000000066737a4c\u003e] event_trigger_write+0x75/0xd0\n [\u003c000000007341e40c\u003e] vfs_write+0xbb/0x2a0\n [\u003c0000000087fde4c2\u003e] ksys_write+0x59/0xd0\n [\u003c00000000581e9cdf\u003e] do_syscall_64+0x3a/0x80\n [\u003c00000000cf3b065c\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0",
"id": "GHSA-7rcj-vmjp-fwmv",
"modified": "2025-03-12T00:31:48Z",
"published": "2025-03-12T00:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49648"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75"
}
],
"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-7RJR-QXC3-7HH3
Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-09-11 18:31In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: don't reissue in case of poll race on multishot request
A previous commit fixed a poll race that can occur, but it's only applicable for multishot requests. For a multishot request, we can safely ignore a spurious wakeup, as we never leave the waitqueue to begin with.
A blunt reissue of a multishot armed request can cause us to leak a buffer, if they are ring provided. While this seems like a bug in itself, it's not really defined behavior to reissue a multishot request directly. It's less efficient to do so as well, and not required to rearm anything like it is for singleshot poll requests.
{
"affected": [],
"aliases": [
"CVE-2023-52895"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: don\u0027t reissue in case of poll race on multishot request\n\nA previous commit fixed a poll race that can occur, but it\u0027s only\napplicable for multishot requests. For a multishot request, we can safely\nignore a spurious wakeup, as we never leave the waitqueue to begin with.\n\nA blunt reissue of a multishot armed request can cause us to leak a\nbuffer, if they are ring provided. While this seems like a bug in itself,\nit\u0027s not really defined behavior to reissue a multishot request directly.\nIt\u0027s less efficient to do so as well, and not required to rearm anything\nlike it is for singleshot poll requests.",
"id": "GHSA-7rjr-qxc3-7hh3",
"modified": "2024-09-11T18:31:02Z",
"published": "2024-08-21T09:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36fc7317cdb16cfeae0f879916995037bb615ac4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8caa03f10bf92cb8657408a6ece6a8a73f96ce13"
}
],
"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-7RP6-P829-5X6W
Vulnerability from github – Published: 2022-03-12 00:00 – Updated: 2024-10-11 18:32drivers/bluetooth/virtio_bt.c in the Linux kernel before 5.16.3 has a memory leak (socket buffers have memory allocated but not freed).
{
"affected": [],
"aliases": [
"CVE-2022-26878"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-11T07:15:00Z",
"severity": "MODERATE"
},
"details": "drivers/bluetooth/virtio_bt.c in the Linux kernel before 5.16.3 has a memory leak (socket buffers have memory allocated but not freed).",
"id": "GHSA-7rp6-p829-5x6w",
"modified": "2024-10-11T18:32:47Z",
"published": "2022-03-12T00:00:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26878"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.17"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d0688421449718c6c5f46e458a378c9b530ba18"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/linux-bluetooth/1A203F5E-FB5E-430C-BEA3-86B191D69D58%40holtmann.org"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/linux-bluetooth/1A203F5E-FB5E-430C-BEA3-86B191D69D58@holtmann.org"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/11/1"
}
],
"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-7RV8-M2WM-JGP4
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-10 18:30In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix throttle_groups memory leak
Add a missing kfree().
{
"affected": [],
"aliases": [
"CVE-2023-53128"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix throttle_groups memory leak\n\nAdd a missing kfree().",
"id": "GHSA-7rv8-m2wm-jgp4",
"modified": "2025-11-10T18:30:30Z",
"published": "2025-05-02T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53128"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/574cc10edaa7dba833764efed8c57ee0e6bf7574"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85349a227eb4a56520adc190c666075f80d4ae70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f305a7b6ca21a665e8d0cf70b5936991a298c93c"
}
],
"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-7V36-PGG4-9J5V
Vulnerability from github – Published: 2026-01-23 15:31 – Updated: 2026-02-26 21:31In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conncount: fix leaked ct in error paths
There are some situations where ct might be leaked as error paths are skipping the refcounted check and return immediately. In order to solve it make sure that the check is always called.
{
"affected": [],
"aliases": [
"CVE-2025-71146"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-23T15:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: fix leaked ct in error paths\n\nThere are some situations where ct might be leaked as error paths are\nskipping the refcounted check and return immediately. In order to solve\nit make sure that the check is always called.",
"id": "GHSA-7v36-pgg4-9j5v",
"modified": "2026-02-26T21:31:26Z",
"published": "2026-01-23T15:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71146"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08fa37f4c8c59c294e9c18fea2d083ee94074e5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b88be7211d21a0d68bb1e56dc805944e3654d6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e2a720766886190a6d35c116794693aabd332b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/325eb61bb30790ea27782203a17b007ce1754a67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bd2b89f4028f250dd1c1625eb3da1979b04a5e8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1ac8dce3a893641bef224ad057932f142b8a36f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f381a33f34dda9e4023e38ba68c943bca83245e9"
}
],
"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-7V52-HC23-9W76
Vulnerability from github – Published: 2022-10-17 19:00 – Updated: 2022-10-19 19:00A vulnerability was found in X.org libX11 and classified as problematic. This issue affects the function _XFreeX11XCBStructure of the file xcb_disp.c. The manipulation of the argument dpy leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211055.
{
"affected": [],
"aliases": [
"CVE-2022-3555"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-404"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-17T13:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in X.org libX11 and classified as problematic. This issue affects the function _XFreeX11XCBStructure of the file xcb_disp.c. The manipulation of the argument dpy leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211055.",
"id": "GHSA-7v52-hc23-9w76",
"modified": "2022-10-19T19:00:22Z",
"published": "2022-10-17T19:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3555"
},
{
"type": "WEB",
"url": "https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=8a368d808fec166b5fb3dfe6312aab22c7ee20af"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.211055"
}
],
"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-7V58-MP27-J7RX
Vulnerability from github – Published: 2025-10-04 09:30 – Updated: 2026-01-27 21:31In the Linux kernel, the following vulnerability has been resolved:
ice: fix Rx page leak on multi-buffer frames
The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.
It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.
If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf().
Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc.
The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page.
Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU.
To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts().
Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet.
For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.
The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.
Move the increment of the ntc local variable to ensure its updated before all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame.
Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.
{
"affected": [],
"aliases": [
"CVE-2025-39948"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T08:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix Rx page leak on multi-buffer frames\n\nThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each\nbuffer in the current frame. This function was introduced as part of\nhandling multi-buffer XDP support in the ice driver.\n\nIt works by iterating over the buffers from first_desc up to 1 plus the\ntotal number of fragments in the frame, cached from before the XDP program\nwas executed.\n\nIf the hardware posts a descriptor with a size of 0, the logic used in\nice_put_rx_mbuf() breaks. Such descriptors get skipped and don\u0027t get added\nas fragments in ice_add_xdp_frag. Since the buffer isn\u0027t counted as a\nfragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don\u0027t\ncall ice_put_rx_buf().\n\nBecause we don\u0027t call ice_put_rx_buf(), we don\u0027t attempt to re-use the\npage or free it. This leaves a stale page in the ring, as we don\u0027t\nincrement next_to_alloc.\n\nThe ice_reuse_rx_page() assumes that the next_to_alloc has been incremented\nproperly, and that it always points to a buffer with a NULL page. Since\nthis function doesn\u0027t check, it will happily recycle a page over the top\nof the next_to_alloc buffer, losing track of the old page.\n\nNote that this leak only occurs for multi-buffer frames. The\nice_put_rx_mbuf() function always handles at least one buffer, so a\nsingle-buffer frame will always get handled correctly. It is not clear\nprecisely why the hardware hands us descriptors with a size of 0 sometimes,\nbut it happens somewhat regularly with \"jumbo frames\" used by 9K MTU.\n\nTo fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on\nall buffers between first_desc and next_to_clean. Borrow the logic of a\nsimilar function in i40e used for this same purpose. Use the same logic\nalso in ice_get_pgcnts().\n\nInstead of iterating over just the number of fragments, use a loop which\niterates until the current index reaches to the next_to_clean element just\npast the current frame. Unlike i40e, the ice_put_rx_mbuf() function does\ncall ice_put_rx_buf() on the last buffer of the frame indicating the end of\npacket.\n\nFor non-linear (multi-buffer) frames, we need to take care when adjusting\nthe pagecnt_bias. An XDP program might release fragments from the tail of\nthe frame, in which case that fragment page is already released. Only\nupdate the pagecnt_bias for the first descriptor and fragments still\nremaining post-XDP program. Take care to only access the shared info for\nfragmented buffers, as this avoids a significant cache miss.\n\nThe xdp_xmit value only needs to be updated if an XDP program is run, and\nonly once per packet. Drop the xdp_xmit pointer argument from\nice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function\ndirectly. This avoids needing to pass the argument and avoids an extra\nbit-wise OR for each buffer in the frame.\n\nMove the increment of the ntc local variable to ensure its updated *before*\nall calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic\nrequires the index of the element just after the current frame.\n\nNow that we use an index pointer in the ring to identify the packet, we no\nlonger need to track or cache the number of fragments in the rx_ring.",
"id": "GHSA-7v58-mp27-j7rx",
"modified": "2026-01-27T21:31:35Z",
"published": "2025-10-04T09:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39948"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80555adb5c892f0e21d243ae96ed997ee520aea9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84bf1ac85af84d354c7a2fdbdc0d4efc8aaec34b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcb5718ebfe7fd64144e3399280440cce361a3ae"
}
],
"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-7V86-RCC3-MQC8
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mxds|mx
The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak.
The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak.
{
"affected": [],
"aliases": [
"CVE-2022-50521"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()\n\nThe ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()\nis not freed after the call, so it leads to memory leak.\n\nThe method results in ACPI buffer is not used, so just pass NULL to\nwmi_evaluate_method() which fixes the memory leak.",
"id": "GHSA-7v86-rcc3-mqc8",
"modified": "2026-02-04T18:30:19Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50521"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14bb4bde3b7b2584734b13747b345caeeb41bea3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17cd8c46cbec4e6ad593fb9159928b8e7608c11a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/379e7794c5e7485193d25d73614fbbd1e1387f6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cf81501356c9e898ad94b2369ffc805f83f7d7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50ac517d6f5348b276f1f663799cf85dce521518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b0f81b0808235967868e01336c976e840217108"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/727cc0147f5066e359aca65cc6cc5e6d64cc15d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87426ce3bd57ad414b6e2436434ef8128986a9a5"
}
],
"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-7V92-Q2QW-6X3C
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix memory leakage
This patch fixes potential memory leakage and seg fault in _gpuvm_import_dmabuf() function
{
"affected": [],
"aliases": [
"CVE-2022-50528"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix memory leakage\n\nThis patch fixes potential memory leakage and seg fault\nin _gpuvm_import_dmabuf() function",
"id": "GHSA-7v92-q2qw-6x3c",
"modified": "2026-02-04T18:30:19Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50528"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7356d8e367d0e025a568e369c4cf575722cac60f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75818afff631e1ea785a82c3e8bb82eb0dee539c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8876793e56ec69b3be2a883b4bc440df3dbb1865"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c65564790048fa416ccd26a8945c7ec0cf9ef0b7"
}
],
"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-7VG2-VV5H-Q272
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-02 21:31In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()
Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak occurs. If kzalloc() for duprule succeeds, but the following kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree them in the error path.
unreferenced object 0xffff122744c50600 (size 192): comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s) hex dump (first 32 bytes): 10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,... 00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'... backtrace: [<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8 [<0000000001bedc67>] kmalloc_trace+0x38/0x88 [<00000000b0612f98>] vcap_dup_rule+0x50/0x460 [<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038 [<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494 [<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698 [<00000000c8766299>] kunit_try_run_case+0xe0/0x20c [<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94 [<00000000f6864acf>] kthread+0x2e8/0x374 [<0000000022e639b3>] ret_from_fork+0x10/0x20
{
"affected": [],
"aliases": [
"CVE-2023-53303"
],
"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\nnet: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()\n\nInject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak\noccurs. If kzalloc() for duprule succeeds, but the following\nkmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree\nthem in the error path.\n\nunreferenced object 0xffff122744c50600 (size 192):\n comm \"kunit_try_catch\", pid 346, jiffies 4294896122 (age 911.812s)\n hex dump (first 32 bytes):\n 10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .\u0027..........,...\n 00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D\u0027...\n backtrace:\n [\u003c00000000394b0db8\u003e] __kmem_cache_alloc_node+0x274/0x2f8\n [\u003c0000000001bedc67\u003e] kmalloc_trace+0x38/0x88\n [\u003c00000000b0612f98\u003e] vcap_dup_rule+0x50/0x460\n [\u003c000000005d2d3aca\u003e] vcap_add_rule+0x8cc/0x1038\n [\u003c00000000eef9d0f8\u003e] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494\n [\u003c00000000cbda607b\u003e] vcap_api_rule_remove_in_front_test+0x1ac/0x698\n [\u003c00000000c8766299\u003e] kunit_try_run_case+0xe0/0x20c\n [\u003c00000000c4fe9186\u003e] kunit_generic_run_threadfn_adapter+0x50/0x94\n [\u003c00000000f6864acf\u003e] kthread+0x2e8/0x374\n [\u003c0000000022e639b3\u003e] ret_from_fork+0x10/0x20",
"id": "GHSA-7vg2-vv5h-q272",
"modified": "2025-12-02T21:31:27Z",
"published": "2025-09-16T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/281f65d29d6da1a9b6907fb0b145aaf34f4e4822"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a26ba60413b2c8f95daf0ee0152cf82abd7bfbe4"
}
],
"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.