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-52F7-5PRX-XWXQ
Vulnerability from github – Published: 2025-02-20 18:31 – Updated: 2025-02-24 18:32A memory leak has been identified in the parseSWF_FILTERLIST function in util/parser.c of libming v0.4.8, which allows attackers to cause a denial of service via a crafted SWF file.
{
"affected": [],
"aliases": [
"CVE-2025-26308"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-20T17:15:12Z",
"severity": "MODERATE"
},
"details": "A memory leak has been identified in the parseSWF_FILTERLIST function in util/parser.c of libming v0.4.8, which allows attackers to cause a denial of service via a crafted SWF file.",
"id": "GHSA-52f7-5prx-xwxq",
"modified": "2025-02-24T18:32:41Z",
"published": "2025-02-20T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26308"
},
{
"type": "WEB",
"url": "https://github.com/libming/libming/issues/326"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-52HV-894W-8QF3
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-03-12 15:32A memory leak issue discovered in parseSWF_GLYPHENTRY in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file.
{
"affected": [],
"aliases": [
"CVE-2024-24149"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T01:44:11Z",
"severity": "MODERATE"
},
"details": "A memory leak issue discovered in parseSWF_GLYPHENTRY in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file.",
"id": "GHSA-52hv-894w-8qf3",
"modified": "2024-03-12T15:32:15Z",
"published": "2024-02-29T03:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24149"
},
{
"type": "WEB",
"url": "https://github.com/libming/libming/issues/310"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-532G-FPXJ-7PXX
Vulnerability from github – Published: 2023-12-12 12:30 – Updated: 2024-06-11 12:31A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-7 LTE (All versions), SIMATIC CP 1243-8 IRC (All versions), SIMATIC CP 1543-1 (All versions), SINAMICS S210 (6SL5...) (All versions >= V6.1 < V6.1 HF2), SIPLUS NET CP 1543-1 (All versions). The webserver implementation of the affected products does not correctly release allocated memory after it has been used.
An attacker with network access could use this vulnerability to cause a denial-of-service condition in the webserver of the affected product.
{
"affected": [],
"aliases": [
"CVE-2023-38380"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-12T12:15:11Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-7 LTE (All versions), SIMATIC CP 1243-8 IRC (All versions), SIMATIC CP 1543-1 (All versions), SINAMICS S210 (6SL5...) (All versions \u003e= V6.1 \u003c V6.1 HF2), SIPLUS NET CP 1543-1 (All versions). The webserver implementation of the affected products does not correctly release allocated memory after it has been used.\n\nAn attacker with network access could use this vulnerability to cause a denial-of-service condition in the webserver of the affected product.",
"id": "GHSA-532g-fpxj-7pxx",
"modified": "2024-06-11T12:31:00Z",
"published": "2023-12-12T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38380"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-139628.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-625862.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-693975.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-693975.pdf"
}
],
"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-5337-PR68-XWQF
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create
The memory pointed to by the fs->any pointer is not freed in the error path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_fs_tt_redirect_any_destroy().
{
"affected": [],
"aliases": [
"CVE-2023-53371"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create\n\nThe memory pointed to by the fs-\u003eany pointer is not freed in the error\npath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.\nFix by freeing the memory in the error path, thereby making the error path\nidentical to mlx5e_fs_tt_redirect_any_destroy().",
"id": "GHSA-5337-pr68-xwqf",
"modified": "2025-12-12T18:30:28Z",
"published": "2025-09-18T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53371"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3250affdc658557a41df9c5fb567723e421f8bf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75df2fe6d160e16be880aacacd521b135d7177c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a75a6f169c3df3a94802314aa61282772ac75b8"
}
],
"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-53CC-XH3P-4X9V
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 15:30In the Linux kernel, the following vulnerability has been resolved:
net: macb: Shuffle the tx ring before enabling tx
Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver.
According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register.
In the current implementation, the code merely resets queue->tx_head
and queue->tx_tail to '0'. This approach presents several issues:
-
Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released.
-
Concurrent write access to
queue->tx_headandqueue->tx_tailmay occur frommacb_tx_poll()ormacb_start_xmit()when these values are reset to '0'. -
The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail',
macb_tx_poll()incorrectly assumes there are no packets to handle becausequeue->tx_head == queue->tx_tail. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem.
To resolve this issue, shuffle the tx ring and tx skb array so that
the first unsent packet is positioned at the start of the tx ring.
Additionally, ensure that updates to queue->tx_head and
queue->tx_tail are properly protected with the appropriate lock.
[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
{
"affected": [],
"aliases": [
"CVE-2026-43371"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macb: Shuffle the tx ring before enabling tx\n\nQuanyang observed that when using an NFS rootfs on an AMD ZynqMp board,\nthe rootfs may take an extended time to recover after a suspend.\nUpon investigation, it was determined that the issue originates from a\nproblem in the macb driver.\n\nAccording to the Zynq UltraScale TRM [1], when transmit is disabled,\nthe transmit buffer queue pointer resets to point to the address\nspecified by the transmit buffer queue base address register.\n\nIn the current implementation, the code merely resets `queue-\u003etx_head`\nand `queue-\u003etx_tail` to \u00270\u0027. This approach presents several issues:\n\n- Packets already queued in the tx ring are silently lost,\n leading to memory leaks since the associated skbs cannot be released.\n\n- Concurrent write access to `queue-\u003etx_head` and `queue-\u003etx_tail` may\n occur from `macb_tx_poll()` or `macb_start_xmit()` when these values\n are reset to \u00270\u0027.\n\n- The transmission may become stuck on a packet that has already been sent\n out, with its \u0027TX_USED\u0027 bit set, but has not yet been processed. However,\n due to the manipulation of \u0027queue-\u003etx_head\u0027 and \u0027queue-\u003etx_tail\u0027,\n `macb_tx_poll()` incorrectly assumes there are no packets to handle\n because `queue-\u003etx_head == queue-\u003etx_tail`. This issue is only resolved\n when a new packet is placed at this position. This is the root cause of\n the prolonged recovery time observed for the NFS root filesystem.\n\nTo resolve this issue, shuffle the tx ring and tx skb array so that\nthe first unsent packet is positioned at the start of the tx ring.\nAdditionally, ensure that updates to `queue-\u003etx_head` and\n`queue-\u003etx_tail` are properly protected with the appropriate lock.\n\n[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm",
"id": "GHSA-53cc-xh3p-4x9v",
"modified": "2026-05-15T15:30:34Z",
"published": "2026-05-08T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43371"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a47c3889fcd843c72aa57fa8c4d06f5801fced4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/403182e0771b250cfde0fe7e1081d095ceaf8230"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58f5d34f88e8f00910b692537f7b2efdb8c3705d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/881a0263d502e1a93ebc13a78254e9ad19520232"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/88f974fe118cb4653f029929ecbca7cfe06132ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6783bfa31a59f34fe4feb1bdbf67791ef3fb0b7"
}
],
"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-53HJ-G53Q-MPCC
Vulnerability from github – Published: 2025-03-07 21:31 – Updated: 2025-03-07 21:31In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well.
Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them.
So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak.
Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.
{
"affected": [],
"aliases": [
"CVE-2022-49729"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred\n\nSimilar to the handling of play_deferred in commit 19cfe912c37b\n(\"Bluetooth: btusb: Fix memory leak in play_deferred\"), we thought\na patch might be needed here as well.\n\nCurrently usb_submit_urb is called directly to submit deferred tx\nurbs after unanchor them.\n\nSo the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb\nand cause memory leak.\n\nPut those urbs in tx_anchor to avoid the leak, and also fix the error\nhandling.",
"id": "GHSA-53hj-g53q-mpcc",
"modified": "2025-03-07T21:31:04Z",
"published": "2025-03-07T21:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49729"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c"
}
],
"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-53QV-XVFG-RJR9
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()
When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur.
Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label.
unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
{
"affected": [],
"aliases": [
"CVE-2025-38419"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T14:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()\n\nWhen rproc-\u003estate = RPROC_DETACHED and rproc_attach() is used\nto attach to the remote processor, if rproc_handle_resources()\nreturns a failure, the resources allocated by imx_rproc_prepare()\nshould be released, otherwise the following memory leak will occur.\n\nSince almost the same thing is done in imx_rproc_prepare() and\nrproc_resource_cleanup(), Function rproc_resource_cleanup() is able\nto deal with empty lists so it is better to fix the \"goto\" statements\nin rproc_attach(). replace the \"unprepare_device\" goto statement with\n\"clean_up_resources\" and get rid of the \"unprepare_device\" label.\n\nunreferenced object 0xffff0000861c5d00 (size 128):\ncomm \"kworker/u12:3\", pid 59, jiffies 4294893509 (age 149.220s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............\nbacktrace:\n [\u003c00000000f949fe18\u003e] slab_post_alloc_hook+0x98/0x37c\n [\u003c00000000adbfb3e7\u003e] __kmem_cache_alloc_node+0x138/0x2e0\n [\u003c00000000521c0345\u003e] kmalloc_trace+0x40/0x158\n [\u003c000000004e330a49\u003e] rproc_mem_entry_init+0x60/0xf8\n [\u003c000000002815755e\u003e] imx_rproc_prepare+0xe0/0x180\n [\u003c0000000003f61b4e\u003e] rproc_boot+0x2ec/0x528\n [\u003c00000000e7e994ac\u003e] rproc_add+0x124/0x17c\n [\u003c0000000048594076\u003e] imx_rproc_probe+0x4ec/0x5d4\n [\u003c00000000efc298a1\u003e] platform_probe+0x68/0xd8\n [\u003c00000000110be6fe\u003e] really_probe+0x110/0x27c\n [\u003c00000000e245c0ae\u003e] __driver_probe_device+0x78/0x12c\n [\u003c00000000f61f6f5e\u003e] driver_probe_device+0x3c/0x118\n [\u003c00000000a7874938\u003e] __device_attach_driver+0xb8/0xf8\n [\u003c0000000065319e69\u003e] bus_for_each_drv+0x84/0xe4\n [\u003c00000000db3eb243\u003e] __device_attach+0xfc/0x18c\n [\u003c0000000072e4e1a4\u003e] device_initial_probe+0x14/0x20",
"id": "GHSA-53qv-xvfg-rjr9",
"modified": "2025-12-23T21:30:22Z",
"published": "2025-07-25T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38419"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5434d9f2fd68722b514c14b417b53a8af02c4d24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7692c9fbedd9087dc9050903f58095915458d9b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82208ce9505abb057afdece7c62a14687c52c9ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92776ca0ccfe78b9bfe847af206bad641fb11121"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9515d74c9d1ae7308a02e8bd4f894eb8137cf8df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c56d6ef2711ee51b54f160ad0f25a381561f0287"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-54JF-P4CR-5XJ6
Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30A Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.
The memory usage can be monitored using the below command.
user@host> show task memory detail | match patroot This issue affects:
Juniper Networks Junos OS
- All versions earlier than 21.2R3-S3;
- 21.3 versions earlier than 21.3R3-S5;
- 21.4 versions earlier than 21.4R3-S3;
- 22.1 versions earlier than 22.1R3;
- 22.2 versions earlier than 22.2R3.
Juniper Networks Junos OS Evolved
- All versions earlier than 21.3R3-S5-EVO;
- 21.4 versions earlier than 21.4R3-EVO;
- 22.1 versions earlier than 22.1R3-EVO;
- 22.2 versions earlier than 22.2R3-EVO.
{
"affected": [],
"aliases": [
"CVE-2024-21613"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-12T01:15:49Z",
"severity": "MODERATE"
},
"details": "\nA Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).\n\nOn all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.\n\nThe memory usage can be monitored using the below command.\n\nuser@host\u003e show task memory detail | match patroot\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n * All versions earlier than 21.2R3-S3;\n * 21.3 versions earlier than 21.3R3-S5;\n * 21.4 versions earlier than 21.4R3-S3;\n * 22.1 versions earlier than 22.1R3;\n * 22.2 versions earlier than 22.2R3.\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n * All versions earlier than 21.3R3-S5-EVO;\n * 21.4 versions earlier than 21.4R3-EVO;\n * 22.1 versions earlier than 22.1R3-EVO;\n * 22.2 versions earlier than 22.2R3-EVO.\n\n\n\n\n\n\n",
"id": "GHSA-54jf-p4cr-5xj6",
"modified": "2024-01-12T03:30:49Z",
"published": "2024-01-12T03:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21613"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA75754"
},
{
"type": "WEB",
"url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-553M-XCVQ-64WH
Vulnerability from github – Published: 2026-01-31 12:30 – Updated: 2026-06-02 15:31In the Linux kernel, the following vulnerability has been resolved:
dmaengine: lpc18xx-dmamux: fix device leak on route allocation
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
{
"affected": [],
"aliases": [
"CVE-2025-71188"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-31T12:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: lpc18xx-dmamux: fix device leak on route allocation\n\nMake sure to drop the reference taken when looking up the DMA mux\nplatform device during route allocation.\n\nNote that holding a reference to a device does not prevent its driver\ndata from going away so there is no point in keeping the reference.",
"id": "GHSA-553m-xcvq-64wh",
"modified": "2026-06-02T15:31:51Z",
"published": "2026-01-31T12:30:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71188"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e47d80f6720f0224efd19bcf081d39637569c10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d396ebfb3049a2b5fac51d2c967db5114b685e8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/499ddae78c4baa9b94df76b2d2eb6b150d15377f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/992eb8055a6e5dbb808672d20d68e60d5a89b12b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fba97baa520c9446df51a64708daf27c5a7ed32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adef147a8d8c3d767abf88ad2c381ffab2993086"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4d63059dee7e7cae0c4d9a532ed558bc90efb55"
}
],
"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-5546-CR76-J66R
Vulnerability from github – Published: 2024-12-29 09:30 – Updated: 2025-01-06 18:31In the Linux kernel, the following vulnerability has been resolved:
udmabuf: fix memory leak on last export_udmabuf() error path
In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a dma_buf owning the udmabuf has already been created; but the error handling in udmabuf_create() will tear down the udmabuf without doing anything about the containing dma_buf.
This leaves a dma_buf in memory that contains a dangling pointer; though that doesn't seem to lead to anything bad except a memory leak.
Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we can give it different error handling.
Note that the shape of this code changed a lot in commit 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios"); but the memory leak seems to have existed since the introduction of udmabuf.
{
"affected": [],
"aliases": [
"CVE-2024-56712"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T09:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: fix memory leak on last export_udmabuf() error path\n\nIn export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a\ndma_buf owning the udmabuf has already been created; but the error handling\nin udmabuf_create() will tear down the udmabuf without doing anything about\nthe containing dma_buf.\n\nThis leaves a dma_buf in memory that contains a dangling pointer; though\nthat doesn\u0027t seem to lead to anything bad except a memory leak.\n\nFix it by moving the dma_buf_fd() call out of export_udmabuf() so that we\ncan give it different error handling.\n\nNote that the shape of this code changed a lot in commit 5e72b2b41a21\n(\"udmabuf: convert udmabuf driver to use folios\"); but the memory leak\nseems to have existed since the introduction of udmabuf.",
"id": "GHSA-5546-cr76-j66r",
"modified": "2025-01-06T18:31:01Z",
"published": "2024-12-29T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56712"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9fc8428d4255c2128da9c4d5cd92e554d0150cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f49856f525acd5bef52ae28b7da2e001bbe7439e"
}
],
"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.