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.
2187 vulnerabilities reference this CWE, most recent first.
GHSA-5RWJ-J5M3-3CHJ
Vulnerability from github – Published: 2021-09-01 18:25 – Updated: 2021-10-21 14:28Impact
In detect-character-encoding v0.3.0 and earlier, allocated memory is not released.
Patches
The problem has been patched in detect-character-encoding v0.3.1.
CVSS score
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C
Base Score: 7.5 (High) Temporal Score: 7.2 (High)
Since detect-character-encoding is a library, the scoring is based on the “reasonable worst-case implementation scenario”, namely, using detect-character-encoding in a program accessible over the internet which becomes unavailable when running out of memory. Depending on your specific implementation, the vulnerability’s severity in your program may be different.
Proof of concept
const express = require("express");
const detectCharacterEncoding = require("detect-character-encoding");
const app = express();
app.get("/", (req, res) => {
detectCharacterEncoding(Buffer.from("foo"));
res.end();
});
app.listen(3000);
hey -n 1000000 http://localhost:3000 (hey) causes the Node.js process to consume more and more memory.
References
- https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588
- https://github.com/sonicdoe/detect-character-encoding/pull/6
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "detect-character-encoding"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-39176"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-31T19:58:46Z",
"nvd_published_at": "2021-08-31T18:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nIn detect-character-encoding v0.3.0 and earlier, allocated memory is not released.\n\n### Patches\n\nThe problem has been patched in [detect-character-encoding v0.3.1](https://github.com/sonicdoe/detect-character-encoding/releases/tag/v0.3.1).\n\n### CVSS score\n\n[CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C)\n\nBase Score: 7.5 (High)\nTemporal Score: 7.2 (High)\n\nSince detect-character-encoding is a library, the scoring is based on the \u201c[reasonable worst-case implementation scenario](https://www.first.org/cvss/v3.1/user-guide#3-7-Scoring-Vulnerabilities-in-Software-Libraries-and-Similar)\u201d, namely, using detect-character-encoding in a program accessible over the internet which becomes unavailable when running out of memory. Depending on your specific implementation, the vulnerability\u2019s severity in your program may be different.\n\n### Proof of concept\n\n```js\nconst express = require(\"express\");\nconst detectCharacterEncoding = require(\"detect-character-encoding\");\n\nconst app = express();\n\napp.get(\"/\", (req, res) =\u003e {\n detectCharacterEncoding(Buffer.from(\"foo\"));\n\n res.end();\n});\n\napp.listen(3000);\n```\n\n`hey -n 1000000 http://localhost:3000` ([`hey`](https://github.com/rakyll/hey)) causes the Node.js process to consume more and more memory.\n\n### References\n\n- https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588\n- https://github.com/sonicdoe/detect-character-encoding/pull/6",
"id": "GHSA-5rwj-j5m3-3chj",
"modified": "2021-10-21T14:28:07Z",
"published": "2021-09-01T18:25:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sonicdoe/detect-character-encoding/security/advisories/GHSA-5rwj-j5m3-3chj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39176"
},
{
"type": "WEB",
"url": "https://github.com/sonicdoe/detect-character-encoding/pull/6"
},
{
"type": "WEB",
"url": "https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588"
},
{
"type": "PACKAGE",
"url": "https://github.com/sonicdoe/detect-character-encoding"
},
{
"type": "WEB",
"url": "https://github.com/sonicdoe/detect-character-encoding/releases/tag/v0.3.1"
}
],
"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"
}
],
"summary": "Missing Release of Memory after Effective Lifetime in detect-character-encoding"
}
GHSA-5V43-2P8Q-45M6
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2023-02-11 03:32Multiple Cisco products are affected by a vulnerability in the way the Snort detection engine processes ICMP traffic that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper memory resource management while the Snort detection engine is processing ICMP packets. An attacker could exploit this vulnerability by sending a series of ICMP packets through an affected device. A successful exploit could allow the attacker to exhaust resources on the affected device, causing the device to reload.
{
"affected": [],
"aliases": [
"CVE-2021-40114"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-27T19:15:00Z",
"severity": "HIGH"
},
"details": "Multiple Cisco products are affected by a vulnerability in the way the Snort detection engine processes ICMP traffic that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper memory resource management while the Snort detection engine is processing ICMP packets. An attacker could exploit this vulnerability by sending a series of ICMP packets through an affected device. A successful exploit could allow the attacker to exhaust resources on the affected device, causing the device to reload.",
"id": "GHSA-5v43-2p8q-45m6",
"modified": "2023-02-11T03:32:49Z",
"published": "2022-05-24T19:18:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40114"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00011.html"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-dos-s2R7W9UU"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5354"
}
],
"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-5V59-J8MR-J2WP
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
net: lantiq_xrx200: restore buffer if memory allocation failed
In a situation where memory allocation fails, an invalid buffer address is stored. When this descriptor is used again, the system panics in the build_skb() function when accessing memory.
{
"affected": [],
"aliases": [
"CVE-2022-49997"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lantiq_xrx200: restore buffer if memory allocation failed\n\nIn a situation where memory allocation fails, an invalid buffer address\nis stored. When this descriptor is used again, the system panics in the\nbuild_skb() function when accessing memory.",
"id": "GHSA-5v59-j8mr-j2wp",
"modified": "2025-11-14T18:31:24Z",
"published": "2025-06-18T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49997"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ef2786e32d93e562cd40601248a14ae090de873"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9c3b1775f80fa21f5bff874027d2ccb10f5d90c"
}
],
"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-5VFQ-RV44-C5FF
Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2025-05-28 18:33By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.
{
"affected": [],
"aliases": [
"CVE-2022-38177"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-21T11:15:00Z",
"severity": "HIGH"
},
"details": "By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.",
"id": "GHSA-5vfq-rv44-c5ff",
"modified": "2025-05-28T18:33:05Z",
"published": "2022-09-22T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38177"
},
{
"type": "WEB",
"url": "https://kb.isc.org/docs/cve-2022-38177"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CV4GQWBPF7Y52J2FA24U6UMHQAOXZEF7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MRHB6J4Z7BKH4HPEKG5D35QGRD6ANNMT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YZJQNUASODNVAWZV6STKG5SD6XIJ446S"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CV4GQWBPF7Y52J2FA24U6UMHQAOXZEF7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MRHB6J4Z7BKH4HPEKG5D35QGRD6ANNMT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YZJQNUASODNVAWZV6STKG5SD6XIJ446S"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-25"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20221228-0010"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5235"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/09/21/3"
}
],
"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-5VP7-VVX6-J367
Vulnerability from github – Published: 2021-12-08 00:01 – Updated: 2021-12-08 00:01There is a Memory leak vulnerability with the codec detection module in Huawei Smartphone.Successful exploitation of this vulnerability may cause the device to restart due to memory exhaustion.
{
"affected": [],
"aliases": [
"CVE-2021-37046"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-07T16:15:00Z",
"severity": "HIGH"
},
"details": "There is a Memory leak vulnerability with the codec detection module in Huawei Smartphone.Successful exploitation of this vulnerability may cause the device to restart due to memory exhaustion.",
"id": "GHSA-5vp7-vvx6-j367",
"modified": "2021-12-08T00:01:26Z",
"published": "2021-12-08T00:01:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37046"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2021/9"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5W42-RMVH-MVW5
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: 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-53414"
],
"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\nscsi: snic: 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 at\nonce.",
"id": "GHSA-5w42-rmvh-mvw5",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53414"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3dec769caf337c55814fbf79ec8c91a3cce23bf3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a46d8bdaf03e8a4bb83f0c363326d9aa66cc122"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/995424f59ab52fb432b26ccb3abced63745ea041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad0e4e2fab928477f74d742e6e77d79245d3d3e7"
}
],
"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-5W45-X7P5-4GFH
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.
{
"affected": [],
"aliases": [
"CVE-2022-49331"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling\n\nError paths do not free previously allocated memory. Add devm_kfree() to\nthose failure paths.",
"id": "GHSA-5w45-x7p5-4gfh",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e"
}
],
"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-5WF2-HXF9-8HXR
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-21 21:30In the Linux kernel, the following vulnerability has been resolved:
tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.
syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences:
sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close()
sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp.
When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is not called.
The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inet_sock_destruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb.
TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skb_queue_purge() call.
In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().
[0]: BUG: memory leak unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53489"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.\n\nsyzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY\nskbs. We can reproduce the problem with these sequences:\n\n sk = socket(AF_INET, SOCK_DGRAM, 0)\n sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE)\n sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1)\n sk.sendto(b\u0027\u0027, MSG_ZEROCOPY, (\u0027127.0.0.1\u0027, 53))\n sk.close()\n\nsendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets\nskb-\u003ecb-\u003eubuf.refcnt to 1, and calls sock_hold(). Here, struct\nubuf_info_msgzc indirectly holds a refcnt of the socket. When the\nskb is sent, __skb_tstamp_tx() clones it and puts the clone into\nthe socket\u0027s error queue with the TX timestamp.\n\nWhen the original skb is received locally, skb_copy_ubufs() calls\nskb_unclone(), and pskb_expand_head() increments skb-\u003ecb-\u003eubuf.refcnt.\nThis additional count is decremented while freeing the skb, but struct\nubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is\nnot called.\n\nThe last refcnt is not released unless we retrieve the TX timestamped\nskb by recvmsg(). Since we clear the error queue in inet_sock_destruct()\nafter the socket\u0027s refcnt reaches 0, there is a circular dependency.\nIf we close() the socket holding such skbs, we never call sock_put()\nand leak the count, sk, and skb.\n\nTCP has the same problem, and commit e0c8bccd40fc (\"net: stream:\npurge sk_error_queue in sk_stream_kill_queues()\") tried to fix it\nby calling skb_queue_purge() during close(). However, there is a\nsmall chance that skb queued in a qdisc or device could be put\ninto the error queue after the skb_queue_purge() call.\n\nIn __skb_tstamp_tx(), the cloned skb should not have a reference\nto the ubuf to remove the circular dependency, but skb_clone() does\nnot call skb_copy_ubufs() for zerocopy skb. So, we need to call\nskb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().\n\n[0]:\nBUG: memory leak\nunreferenced object 0xffff88800c6d2d00 (size 1152):\n comm \"syz-executor392\", pid 264, jiffies 4294785440 (age 13.044s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................\n 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [\u003c0000000055636812\u003e] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024\n [\u003c0000000054d77b7a\u003e] sk_alloc+0x3b/0x800 net/core/sock.c:2083\n [\u003c0000000066f3c7e0\u003e] inet_create net/ipv4/af_inet.c:319 [inline]\n [\u003c0000000066f3c7e0\u003e] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245\n [\u003c000000009b83af97\u003e] __sock_create+0x2ab/0x550 net/socket.c:1515\n [\u003c00000000b9b11231\u003e] sock_create net/socket.c:1566 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket_create net/socket.c:1603 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket_create net/socket.c:1588 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket+0x138/0x250 net/socket.c:1636\n [\u003c000000004fb45142\u003e] __do_sys_socket net/socket.c:1649 [inline]\n [\u003c000000004fb45142\u003e] __se_sys_socket net/socket.c:1647 [inline]\n [\u003c000000004fb45142\u003e] __x64_sys_socket+0x73/0xb0 net/socket.c:1647\n [\u003c0000000066999e0e\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [\u003c0000000066999e0e\u003e] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80\n [\u003c0000000017f238c1\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nBUG: memory leak\nunreferenced object 0xffff888017633a00 (size 240):\n comm \"syz-executor392\", pid 264, jiffies 4294785440 (age 13.044s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m.....\n backtrace:\n [\u003c000000002b1c4368\u003e] __alloc_skb+0x229/0x320 net/core/skbuff.c:497\n [\u003c00000000143579a6\u003e] alloc_skb include/linux/skbuff.h:1265 [inline]\n [\u003c00000000143579a6\u003e] sock_omalloc+0xaa/0x190 net/core/sock.c:2596\n [\u003c00000000be626478\u003e] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline]\n [\u003c00000000be626478\u003e]\n---truncated---",
"id": "GHSA-5wf2-hxf9-8hxr",
"modified": "2026-01-21T21:30:27Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f69c086b20e27763af28145981435423f088268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/230a5ed7d813fb516de81d23f09d7506753e41e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/281072fb2a7294cde7acbf5375b879f40a8001b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30290f210ba7426ff7592fe2eb4114b1b5bad219"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/426384dd4980040651536fef5feac4dcc4d7ee4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50749f2dd6854a41830996ad302aef2ffaf011d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/602fa8af44fd55a58f9e94eb673e8adad2c6cc46"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb52e7f24c1d01a536a847dff0d1d95889cc3b5c"
}
],
"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-5WFX-MRW3-HHMX
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2023-01-18 00:30A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.
{
"affected": [],
"aliases": [
"CVE-2019-19075"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-18T06:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.",
"id": "GHSA-5wfx-mrw3-hhmx",
"modified": "2023-01-18T00:30:25Z",
"published": "2022-05-24T17:01:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19075"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/6402939ec86eaf226c8b8ae00ed983936b164908"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.8"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4208-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4210-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4226-1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00029.html"
}
],
"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-5WHM-XP9M-869G
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-23 03:30In the Linux kernel, the following vulnerability has been resolved:
clk: tegra: tegra124-emc: Fix potential memory leak
The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked.
{
"affected": [],
"aliases": [
"CVE-2023-53505"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: tegra: tegra124-emc: Fix potential memory leak\n\nThe tegra and tegra needs to be freed in the error handling path, otherwise\nit will be leaked.",
"id": "GHSA-5whm-xp9m-869g",
"modified": "2026-01-23T03:30:29Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53505"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801c8341f7aff07c494b53e627970b72635af5d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e969c144d908ea9387442659f103d374c8ff682d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd1c117bb5d7e033bf1aa25ac97ff421f81a1199"
}
],
"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.