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.
2091 vulnerabilities reference this CWE, most recent first.
GHSA-2H7H-J22F-V4P9
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22SmartDefragDriver.sys (2.0) in IObit Smart Defrag 6 never frees an executable kernel pool that is allocated with user defined bytes and size when IOCTL 0x9C401CC0 is called. This kernel pointer can be leaked if the kernel pool becomes a "big" pool.
{
"affected": [],
"aliases": [
"CVE-2019-6493"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-11T20:29:00Z",
"severity": "MODERATE"
},
"details": "SmartDefragDriver.sys (2.0) in IObit Smart Defrag 6 never frees an executable kernel pool that is allocated with user defined bytes and size when IOCTL 0x9C401CC0 is called. This kernel pointer can be leaked if the kernel pool becomes a \"big\" pool.",
"id": "GHSA-2h7h-j22f-v4p9",
"modified": "2022-05-13T01:22:43Z",
"published": "2022-05-13T01:22:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6493"
},
{
"type": "WEB",
"url": "https://downwithup.github.io/CVEPosts.html"
},
{
"type": "WEB",
"url": "https://www.iobit.com/en/iobitsmartdefrag.php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2HF5-VJ7W-QQ52
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-03 21:30In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix memory leak in lbs_init_adapter()
When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path.
{
"affected": [],
"aliases": [
"CVE-2022-50294"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: libertas: fix memory leak in lbs_init_adapter()\n\nWhen kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not\nreleased. Add free memory to processing error path.",
"id": "GHSA-2hf5-vj7w-qq52",
"modified": "2025-12-03T21:30:59Z",
"published": "2025-09-15T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/037f84c0bfae5c436c651d0e804264e2648010ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16a03958618fb91bb1bc7077cf3211055162cc2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23b34e08de5c2380414c9d3c33e8235094bcccae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c102ad59bfa66c0f6662af64fa3b9007b02c20f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/653d13a73e498d0bb6aeaf689aaa960defa7878b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98e0ff6980c89239d9e5d3da90d791c2383dc23a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c8f50c7433bdfba1588831c413136ecc3f29f99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d46c33f667b05c22bc5c5b69aa730349c4b6fe31"
}
],
"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-2HGR-Q34G-9RRW
Vulnerability from github – Published: 2023-08-29 00:32 – Updated: 2023-11-04 03:30A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause a double-deactivations of catchall elements, which results in a memory leak.
{
"affected": [],
"aliases": [
"CVE-2023-4569"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-28T22:15:10Z",
"severity": "MODERATE"
},
"details": "A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause a double-deactivations of catchall elements, which results in a memory leak.",
"id": "GHSA-2hgr-q34g-9rrw",
"modified": "2023-11-04T03:30:18Z",
"published": "2023-08-29T00:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4569"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-4569"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2235470"
},
{
"type": "WEB",
"url": "https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5492"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2HQP-7448-QRW3
Vulnerability from github – Published: 2022-09-17 00:00 – Updated: 2022-09-22 00:00The MPTCP module has the memory leak vulnerability. Successful exploitation of this vulnerability can cause memory leaks.
{
"affected": [],
"aliases": [
"CVE-2022-39005"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-16T18:15:00Z",
"severity": "HIGH"
},
"details": "The MPTCP module has the memory leak vulnerability. Successful exploitation of this vulnerability can cause memory leaks.",
"id": "GHSA-2hqp-7448-qrw3",
"modified": "2022-09-22T00:00:31Z",
"published": "2022-09-17T00:00:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39005"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2022/9"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-phones-202209-0000001392278845"
}
],
"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-2HWX-F32F-7QP6
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-14 21:31In the Linux kernel, the following vulnerability has been resolved:
i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers()
The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup attribute to automatically free the memory when the variable goes out of scope.
{
"affected": [],
"aliases": [
"CVE-2026-53030"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers()\n\nThe xfer structure allocated by renesas_i3c_alloc_xfer() was never freed\nin the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup\nattribute to automatically free the memory when the variable goes out of\nscope.",
"id": "GHSA-2hwx-f32f-7qp6",
"modified": "2026-07-14T21:31:29Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b6a7e94be678d34a9ccb9db7e2443ae02ad2bc8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab8f00ffcca0f618fb8198d358f24728950d9860"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7665c3b4f575251e449e2656879392346ca612b"
}
],
"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-2J2F-9HJH-V2XM
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-17 21:31In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().
syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0]
The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO.
ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup().
The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup():
CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________.'
local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices.
If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame().
Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame().
[0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm "syz.0.17", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm "syz.0.17", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-23150"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().\n\nsyzbot reported various memory leaks related to NFC, struct\nnfc_llcp_sock, sk_buff, nfc_dev, etc. [0]\n\nThe leading log hinted that nfc_llcp_send_ui_frame() failed\nto allocate skb due to sock_error(sk) being -ENXIO.\n\nENXIO is set by nfc_llcp_socket_release() when struct\nnfc_llcp_local is destroyed by local_cleanup().\n\nThe problem is that there is no synchronisation between\nnfc_llcp_send_ui_frame() and local_cleanup(), and skb\ncould be put into local-\u003etx_queue after it was purged in\nlocal_cleanup():\n\n CPU1 CPU2\n ---- ----\n nfc_llcp_send_ui_frame() local_cleanup()\n |- do { \u0027\n |- pdu = nfc_alloc_send_skb(..., \u0026err)\n | .\n | |- nfc_llcp_socket_release(local, false, ENXIO);\n | |- skb_queue_purge(\u0026local-\u003etx_queue); |\n | \u0027 |\n |- skb_queue_tail(\u0026local-\u003etx_queue, pdu); |\n ... |\n |- pdu = nfc_alloc_send_skb(..., \u0026err) |\n ^._________________________________.\u0027\n\nlocal_cleanup() is called for struct nfc_llcp_local only\nafter nfc_llcp_remove_local() unlinks it from llcp_devices.\n\nIf we hold local-\u003etx_queue.lock then, we can synchronise\nthe thread and nfc_llcp_send_ui_frame().\n\nLet\u0027s do that and check list_empty(\u0026local-\u003elist) before\nqueuing skb to local-\u003etx_queue in nfc_llcp_send_ui_frame().\n\n[0]:\n[ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)\n[ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nBUG: memory leak\nunreferenced object 0xffff8881272f6800 (size 1024):\n comm \"syz.0.17\", pid 6096, jiffies 4294942766\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 \u0027..@............\n backtrace (crc da58d84d):\n kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n slab_post_alloc_hook mm/slub.c:4979 [inline]\n slab_alloc_node mm/slub.c:5284 [inline]\n __do_kmalloc_node mm/slub.c:5645 [inline]\n __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658\n kmalloc_noprof include/linux/slab.h:961 [inline]\n sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239\n sk_alloc+0x36/0x360 net/core/sock.c:2295\n nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979\n llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044\n nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31\n __sock_create+0x1a9/0x340 net/socket.c:1605\n sock_create net/socket.c:1663 [inline]\n __sys_socket_create net/socket.c:1700 [inline]\n __sys_socket+0xb9/0x1a0 net/socket.c:1747\n __do_sys_socket net/socket.c:1761 [inline]\n __se_sys_socket net/socket.c:1759 [inline]\n __x64_sys_socket+0x1b/0x30 net/socket.c:1759\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nBUG: memory leak\nunreferenced object 0xffff88810fbd9800 (size 240):\n comm \"syz.0.17\", pid 6096, jiffies 4294942850\n hex dump (first 32 bytes):\n 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......\n 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/\u0027....\n backtrace (crc 6cc652b1):\n kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n slab_post_alloc_hook mm/slub.c:4979 [inline]\n slab_alloc_node mm/slub.c:5284 [inline]\n kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336\n __alloc_skb+0x203/0x240 net/core/skbuff.c:660\n alloc_skb include/linux/skbuff.h:1383 [inline]\n alloc_skb_with_frags+0x69/0x3f0 net/core/sk\n---truncated---",
"id": "GHSA-2j2f-9hjh-v2xm",
"modified": "2026-03-17T21:31:41Z",
"published": "2026-02-14T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23150"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/165c34fb6068ff153e3fc99a932a80a9d5755709"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3098e5c8af0f4c8f7eebbb370798df8aa2e12ba5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61858cbce6ca4bef9ed116c689a4be9520841339"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65e976e1f474ae3bf5681d7abafb8f3fdb34b8cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6734ff1ac6beba1d0c22dc9a3dc1849b773b511f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab660cb8e17aa93426d1e821c2cce60e4b9bc56a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8d002626d434f5fea9085e2557711c16a15cec6"
}
],
"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-2J9F-HMX4-CVGR
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-09-06 18:31In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leaks and crashes while performing a soft reset
The second tagged commit introduced a UAF, as it removed restoring q_vector->vport pointers after reinitializating the structures. This is due to that all queue allocation functions are performed here with the new temporary vport structure and those functions rewrite the backpointers to the vport. Then, this new struct is freed and the pointers start leading to nowhere.
But generally speaking, the current logic is very fragile. It claims to be more reliable when the system is low on memory, but in fact, it consumes two times more memory as at the moment of running this function, there are two vports allocated with their queues and vectors. Moreover, it claims to prevent the driver from running into "bad state", but in fact, any error during the rebuild leaves the old vport in the partially allocated state. Finally, if the interface is down when the function is called, it always allocates a new queue set, but when the user decides to enable the interface later on, vport_open() allocates them once again, IOW there's a clear memory leak here.
Just don't allocate a new queue set when performing a reset, that solves crashes and memory leaks. Readd the old queue number and reopen the interface on rollback - that solves limbo states when the device is left disabled and/or without HW queues enabled.
{
"affected": [],
"aliases": [
"CVE-2024-44964"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leaks and crashes while performing a soft reset\n\nThe second tagged commit introduced a UAF, as it removed restoring\nq_vector-\u003evport pointers after reinitializating the structures.\nThis is due to that all queue allocation functions are performed here\nwith the new temporary vport structure and those functions rewrite\nthe backpointers to the vport. Then, this new struct is freed and\nthe pointers start leading to nowhere.\n\nBut generally speaking, the current logic is very fragile. It claims\nto be more reliable when the system is low on memory, but in fact, it\nconsumes two times more memory as at the moment of running this\nfunction, there are two vports allocated with their queues and vectors.\nMoreover, it claims to prevent the driver from running into \"bad state\",\nbut in fact, any error during the rebuild leaves the old vport in the\npartially allocated state.\nFinally, if the interface is down when the function is called, it always\nallocates a new queue set, but when the user decides to enable the\ninterface later on, vport_open() allocates them once again, IOW there\u0027s\na clear memory leak here.\n\nJust don\u0027t allocate a new queue set when performing a reset, that solves\ncrashes and memory leaks. Readd the old queue number and reopen the\ninterface on rollback - that solves limbo states when the device is left\ndisabled and/or without HW queues enabled.",
"id": "GHSA-2j9f-hmx4-cvgr",
"modified": "2024-09-06T18:31:29Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44964"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b289f8d91537ec1e4f9c7b38b31b90d93b1419b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f01032a2ca099ec8d619aaa916c3762aa62495df"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2JPC-GRXP-P4W8
Vulnerability from github – Published: 2022-07-21 00:00 – Updated: 2022-07-30 00:00A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause a Denial of Service (DoS). On all Junos platforms, the Kernel Routing Table (KRT) queue can get stuck due to a memory leak triggered by interface flaps or route churn leading to RIB and PFEs getting out of sync. The memory leak causes RTNEXTHOP/route and next-hop memory pressure issue and the KRT queue will eventually get stuck with the error- 'ENOMEM -- Cannot allocate memory'. The out-of-sync state between RIB and FIB can be seen with the "show route" and "show route forwarding-table" command. This issue will lead to failures for adding new routes. The KRT queue status can be checked using the CLI command "show krt queue": user@host > show krt state High-priority add queue: 1 queued ADD nhtype Router index 0 (31212) error 'ENOMEM -- Cannot allocate memory' kqp '0x8ad5e40' The following messages will be observed in /var/log/messages, which indicate high memory for routes/nexthops: host rpd[16279]: RPD_RT_HWM_NOTICE: New RIB highwatermark for routes: 266 [2022-03-04 05:06:07] host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host kernel: rts_veto_net_delayed_unref_limit: Route/nexthop memory is severe pressure. User Application to perform recovery actions. O p 8 err 12, rtsm_id 0:-1, msg type 10, veto simulation: 0. host kernel: rts_veto_net_delayed_unref_limit: Memory usage of M_RTNEXTHOP type = (806321208) Max size possible for M_RTNEXTHOP type = (689432176) Current delayed unref = (0), Max delayed unref on this platform = (120000) Current delayed weight unref = (0) Max delayed weight unref on this platform = (400000) curproc = rpd. This issue affects: Juniper Networks Junos OS 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2-S1, 21.3R3; 21.4 versions prior to 21.4R1-S2, 21.4R2; This issue does not affect Juniper Networks Junos OS versions prior to 21.2R1.
{
"affected": [],
"aliases": [
"CVE-2022-22209"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-20T15:15:00Z",
"severity": "HIGH"
},
"details": "A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause a Denial of Service (DoS). On all Junos platforms, the Kernel Routing Table (KRT) queue can get stuck due to a memory leak triggered by interface flaps or route churn leading to RIB and PFEs getting out of sync. The memory leak causes RTNEXTHOP/route and next-hop memory pressure issue and the KRT queue will eventually get stuck with the error- \u0027ENOMEM -- Cannot allocate memory\u0027. The out-of-sync state between RIB and FIB can be seen with the \"show route\" and \"show route forwarding-table\" command. This issue will lead to failures for adding new routes. The KRT queue status can be checked using the CLI command \"show krt queue\": user@host \u003e show krt state High-priority add queue: 1 queued ADD nhtype Router index 0 (31212) error \u0027ENOMEM -- Cannot allocate memory\u0027 kqp \u00270x8ad5e40\u0027 The following messages will be observed in /var/log/messages, which indicate high memory for routes/nexthops: host rpd[16279]: RPD_RT_HWM_NOTICE: New RIB highwatermark for routes: 266 [2022-03-04 05:06:07] host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host kernel: rts_veto_net_delayed_unref_limit: Route/nexthop memory is severe pressure. User Application to perform recovery actions. O p 8 err 12, rtsm_id 0:-1, msg type 10, veto simulation: 0. host kernel: rts_veto_net_delayed_unref_limit: Memory usage of M_RTNEXTHOP type = (806321208) Max size possible for M_RTNEXTHOP type = (689432176) Current delayed unref = (0), Max delayed unref on this platform = (120000) Current delayed weight unref = (0) Max delayed weight unref on this platform = (400000) curproc = rpd. This issue affects: Juniper Networks Junos OS 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2-S1, 21.3R3; 21.4 versions prior to 21.4R1-S2, 21.4R2; This issue does not affect Juniper Networks Junos OS versions prior to 21.2R1.",
"id": "GHSA-2jpc-grxp-p4w8",
"modified": "2022-07-30T00:00:16Z",
"published": "2022-07-21T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22209"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA69713"
}
],
"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-2JXW-CWMM-P22X
Vulnerability from github – Published: 2025-09-18 18:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fw: fix memory leak in debugfs
Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object.
{
"affected": [],
"aliases": [
"CVE-2023-53422"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T16:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: fw: fix memory leak in debugfs\n\nFix a memory leak that occurs when reading the fw_info\nfile all the way, since we return NULL indicating no\nmore data, but don\u0027t free the status tracking object.",
"id": "GHSA-2jxw-cwmm-p22x",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53422"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d90d2f4a018fe8cfd65068bc6350b6222be4852"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89496d6cff297c88fe0286a440c380ceb172da2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b830ba20b43be52eae7d4087b61a0079dec56820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e302e9ca14a86a80eadfb24a34d8675aadaf3ef3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe17124282da055cb2e53f0131521459b5c7866c"
}
],
"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-2M3M-X4CJ-RQRM
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: pxa27x_udc: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
{
"affected": [],
"aliases": [
"CVE-2023-53407"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: pxa27x_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.",
"id": "GHSA-2m3m-x4cj-rqrm",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53407"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67c931a3f2f061bf457995fd21fff114325e0c30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a6952fa0366d4408eb8695af1a0578c39ec718a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8da78a60f3323ce7aac589d49fb82f71a04bc835"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b14d188d0d0b86e2180525aefd570dbb6ebd6aa9"
}
],
"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.