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-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"
}
]
}
GHSA-7VPH-XJ83-RW6V
Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-10-24 18:30Vulnerability in Realtek RtsPer driver for PCIe Card Reader (RtsPer.sys) before 10.0.22000.21355 and Realtek RtsUer driver for USB Card Reader (RtsUer.sys) before 10.0.22000.31274 allows for the leakage of kernel memory from both the stack and the heap.
{
"affected": [],
"aliases": [
"CVE-2022-25479"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T19:15:11Z",
"severity": "MODERATE"
},
"details": "Vulnerability in Realtek RtsPer driver for PCIe Card Reader (RtsPer.sys) before 10.0.22000.21355 and Realtek RtsUer driver for USB Card Reader (RtsUer.sys) before 10.0.22000.31274 allows for the leakage of kernel memory from both the stack and the heap.",
"id": "GHSA-7vph-xj83-rw6v",
"modified": "2024-10-24T18:30:40Z",
"published": "2024-07-02T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25479"
},
{
"type": "WEB",
"url": "https://gist.github.com/zwclose/feb16f1424779a61cb1d9f6d5681408a"
},
{
"type": "WEB",
"url": "https://www.realtek.com/images/safe-report/Realtek_RtsPer_RtsUer_Security_Advisory_Report.pdf"
},
{
"type": "WEB",
"url": "https://zwclose.github.io/2024/10/14/rtsper1.html"
},
{
"type": "WEB",
"url": "http://realtek.com"
}
],
"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-7VQ8-6V9J-P4JG
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix leaks when hci_cmd_sync_queue_once fails
When hci_cmd_sync_queue_once() returns with error, the destroy callback will not be called.
Fix leaking references / memory on these failures.
{
"affected": [],
"aliases": [
"CVE-2026-43021"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix leaks when hci_cmd_sync_queue_once fails\n\nWhen hci_cmd_sync_queue_once() returns with error, the destroy callback\nwill not be called.\n\nFix leaking references / memory on these failures.",
"id": "GHSA-7vq8-6v9j-p4jg",
"modified": "2026-05-08T15:31:14Z",
"published": "2026-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43021"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fd74178d4b16dcf47179da634ea9d7c02e3608b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aca377208e7f7322bf4e107cdec6e7d7e8aa7a88"
}
],
"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-7W5F-39WQ-4475
Vulnerability from github – Published: 2022-05-24 17:13 – Updated: 2022-05-24 17:13The kernel memory usage represented as "temp" via 'show system virtual-memory' may constantly increase when Integrated Routing and Bridging (IRB) is configured with multiple underlay physical interfaces, and one interface flaps. This memory leak can affect running daemons (processes), leading to an extended Denial of Service (DoS) condition. Usage of "temp" virtual memory, shown here by a constantly increasing value of outstanding Requests, can be monitored by executing the 'show system virtual-memory' command as shown below: user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 10551 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6460 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 16101 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6665 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 21867 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6858 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S5, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R2-S5, 18.2R3; 18.2X75 versions prior to 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D60; 18.3 versions prior to 18.3R1-S5, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2. This issue does not affect Juniper Networks Junos OS 12.3 and 15.1.
{
"affected": [],
"aliases": [
"CVE-2020-1625"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-08T20:15:00Z",
"severity": "LOW"
},
"details": "The kernel memory usage represented as \"temp\" via \u0027show system virtual-memory\u0027 may constantly increase when Integrated Routing and Bridging (IRB) is configured with multiple underlay physical interfaces, and one interface flaps. This memory leak can affect running daemons (processes), leading to an extended Denial of Service (DoS) condition. Usage of \"temp\" virtual memory, shown here by a constantly increasing value of outstanding Requests, can be monitored by executing the \u0027show system virtual-memory\u0027 command as shown below: user@junos\u003e show system virtual-memory |match \"fpc|type|temp\" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 10551 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6460 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos\u003e show system virtual-memory |match \"fpc|type|temp\" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 16101 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6665 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos\u003e show system virtual-memory |match \"fpc|type|temp\" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 21867 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6858 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S5, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R2-S5, 18.2R3; 18.2X75 versions prior to 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D60; 18.3 versions prior to 18.3R1-S5, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2. This issue does not affect Juniper Networks Junos OS 12.3 and 15.1.",
"id": "GHSA-7w5f-39wq-4475",
"modified": "2022-05-24T17:13:52Z",
"published": "2022-05-24T17:13:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1625"
},
{
"type": "WEB",
"url": "https://kb.juniper.net"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11004"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7W99-2X38-38JP
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()
In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak.
Replace it with a goto label to ensure proper cleanup.
{
"affected": [],
"aliases": [
"CVE-2026-45954"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()\n\nIn au1200fb_drv_probe(), when platform_get_irq fails(), it directly\nreturns from the function with an error code, which causes a memory\nleak.\n\nReplace it with a goto label to ensure proper cleanup.",
"id": "GHSA-7w99-2x38-38jp",
"modified": "2026-06-16T03:30:32Z",
"published": "2026-05-27T15:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45954"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/071d8fb757a8318f72c8e02898c2cf7e14e21fb6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d4202ee6494c0d576cdc104b12e0834ca8136a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e5349e54113e2dce1a659c57935e18032742e56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/762a26818934241b8b0172a229d2cf5d87260e40"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81831d56b723bc1090ce3158feddaca88e85f939"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b024a8efee0f55d330a1cdd3eac8f79ac5acd3be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd1ad63e11b2a568e98de536f319054d2de29f56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce4e25198a6aaaaf36248edf8daf3d744ec8e309"
}
],
"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-7WQ4-C573-G7Q5
Vulnerability from github – Published: 2025-07-04 15:31 – Updated: 2025-11-18 18:32In the Linux kernel, the following vulnerability has been resolved:
media: imagination: fix a potential memory leak in e5010_probe()
Add video_device_release() to release the memory allocated by video_device_alloc() if something goes wrong.
{
"affected": [],
"aliases": [
"CVE-2025-38228"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-04T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imagination: fix a potential memory leak in e5010_probe()\n\nAdd video_device_release() to release the memory allocated by\nvideo_device_alloc() if something goes wrong.",
"id": "GHSA-7wq4-c573-g7q5",
"modified": "2025-11-18T18:32:47Z",
"published": "2025-07-04T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38228"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a2bd7df402decbdefd0acb64ba4e17a0a2a4117"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/609ba05b9484856b08869f827a6edee51d51b5f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fac3b9a91fa099d9bad29648127c0328d6c478c3"
}
],
"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.