Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Abstraction: Class · Status: Draft

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

2909 vulnerabilities reference this CWE, most recent first.

GHSA-33X4-8657-2C2G

Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31
VLAI
Details

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

raw: Fix a data-race around sysctl_raw_l3mdev_accept.

While reading sysctl_raw_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nraw: Fix a data-race around sysctl_raw_l3mdev_accept.\n\nWhile reading sysctl_raw_l3mdev_accept, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.",
  "id": "GHSA-33x4-8657-2c2g",
  "modified": "2025-03-12T00:31:47Z",
  "published": "2025-03-12T00:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49631"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/038a87b3e460d2ee579c8b1bd3890d816d6687b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1dace014928e6e385363032d359a04dee9158af0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/46e9c46203fd4676720ddca0fef7eff26826648e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab5adca2e17d6595f3fc0e25ccb6bcbe2e01ca4f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc9540ba5b3652c473af7e54892a48cdced87983"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3422-45QX-4M3X

Vulnerability from github – Published: 2022-05-17 03:13 – Updated: 2022-05-17 03:13
VLAI
Details

Race condition in the IPv6-to-IPv4 functionality in Cisco IOS 15.3S in the Performance Routing Engine (PRE) module on UBR devices allows remote attackers to cause a denial of service (NULL pointer free and module crash) by triggering intermittent connectivity with many IPv6 CPE devices, aka Bug ID CSCug47366.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-4199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-06-27T10:59:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in the IPv6-to-IPv4 functionality in Cisco IOS 15.3S in the Performance Routing Engine (PRE) module on UBR devices allows remote attackers to cause a denial of service (NULL pointer free and module crash) by triggering intermittent connectivity with many IPv6 CPE devices, aka Bug ID CSCug47366.",
  "id": "GHSA-3422-45qx-4m3x",
  "modified": "2022-05-17T03:13:42Z",
  "published": "2022-05-17T03:13:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-4199"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/viewAlert.x?alertId=39423"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/75335"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1032692"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-344P-V638-Q9GC

Vulnerability from github – Published: 2022-10-21 12:00 – Updated: 2022-10-25 12:00
VLAI
Details

A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-21T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability.",
  "id": "GHSA-344p-v638-q9gc",
  "modified": "2022-10-25T12:00:15Z",
  "published": "2022-10-21T12:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3635"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.211934"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-345P-7CG4-V4C7

Vulnerability from github – Published: 2026-02-04 20:04 – Updated: 2026-02-09 14:52
VLAI
Summary
@modelcontextprotocol/sdk has cross-client data leak via shared server/transport instance reuse
Details

Summary

Cross-client data leak via two distinct issues: (1) reusing a single StreamableHTTPServerTransport across multiple client requests, and (2) reusing a single McpServer/Server instance across multiple transports. Both are most common in stateless deployments.

Impact

This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both.

Issue 1: Transport re-use

What happens: When a single StreamableHTTPServerTransport instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. The transport maintains an internal requestId → stream mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream.

What is affected: All request types — tools/call, resources/read, prompts/get, etc. No server-initiated features are required to trigger this.

Conditions: - A single StreamableHTTPServerTransport instance is reused across multiple client requests (most common in stateless mode without sessionIdGenerator) - Two or more clients send requests concurrently - Clients generate overlapping JSON-RPC message IDs (the SDK's default client uses an incrementing counter starting at 0)

Issue 2: Server/Protocol re-use

What happens: When a single McpServer (or Server) instance is connect()ed to multiple transports (one per client), the Protocol's internal this._transport reference is silently overwritten. The final response to a request is routed correctly (the Protocol captures the transport reference at request time), but any server-to-client messages sent during request handling use the shared this._transport reference, which may point to a different client's transport.

What is affected: This depends on what features your server uses:

  • Final responses (the return value from a tool/resource/prompt handler): Affected in most cases. The Protocol captures this._transport at request-handling time, not the transport that delivered the request. This means:
    • If a request is already in-flight when a second connect() occurs (i.e., the request arrived before the transport was overwritten), the captured reference is correct and the response routes properly.
    • If a request arrives on the old transport after a second connect() has overwritten this._transport, the captured reference points to the new transport, and the response is mis-routed. The requesting client will time out.
  • Progress notifications sent during tool execution via sendNotification: Affected. These are dispatched through this._transport. When the transport has been overwritten and message IDs collide on the new transport, notifications are routed to the wrong client's HTTP stream.
  • Sampling (createMessage) and elicitation requests sent during tool execution via sendRequest: Affected. Same mechanism — the request is sent to the wrong client.
  • Spontaneous server-initiated notifications (outside any request handler): Affected. These are sent to whichever client's transport was most recently connected.

Conditions: - A single McpServer/Server instance is connect()ed to multiple transports across requests or sessions - Two or more clients connect concurrently - For in-request notifications/requests: message ID collision on the other transport is required for silent data leaking (the SDK's default client uses an incrementing counter starting at 0). Without collision, the transport will throw an error rather than misroute. - For spontaneous notifications: no collision needed, messages are always sent to the last-connected client's transport

How to tell if you're affected

  • You use sessionIdGenerator (stateful mode) with a new McpServer per session → not affected by either issue. Each session has its own transport and server instance.
  • You use sessionIdGenerator but share a single McpServer across sessions → not affected by Issue 1 (transport re-use), but affected by Issue 2 (server re-use) if your tools send progress notifications, sampling, or elicitation during execution.
  • You are in stateless mode and reuse both a transport and a server across requests → affected by both issues; all request types can leak.
  • You are in stateless mode and create a new transport per request, but reuse the server → affected by Issue 2 only; safe if your tools only return results without sending progress notifications, sampling, or elicitation during execution.
  • You create a new server + transport per request → not affected.
  • Single-client environments (e.g., local development with one IDE) → not affected.

Patches

The fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:

  1. Protocol.connect() now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2)
  2. Stateless StreamableHTTPServerTransport.handleRequest() now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1)
  3. In-flight request handler abort controllers are cleaned up on close(), and sendNotification/sendRequest in handler extras check the abort signal before sending, preventing messages from leaking after a transport is replaced

Servers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.

Workarounds

If you cannot upgrade immediately, ensure your server creates fresh McpServer and transport instances for each request (stateless) or session (stateful):

// Stateless mode: create new server + transport per request
app.post('/mcp', async (req, res) => {
  const server = new McpServer({ name: 'my-server', version: '1.0.0' });
  // ... register tools, resources, etc.
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  await server.connect(transport);
  await transport.handleRequest(req, res);
});

// Stateful mode: create new server + transport per session
const sessions = new Map();
app.post('/mcp', async (req, res) => {
  const sessionId = req.headers['mcp-session-id'];
  if (sessions.has(sessionId)) {
    await sessions.get(sessionId).transport.handleRequest(req, res);
  } else {
    const server = new McpServer({ name: 'my-server', version: '1.0.0' });
    // ... register tools, resources, etc.
    const transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: () => randomUUID()
    });
    await server.connect(transport);
    sessions.set(transport.sessionId, { server, transport });
    await transport.handleRequest(req, res);
  }
});
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.25.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-04T20:04:16Z",
    "nvd_published_at": "2026-02-04T22:15:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nCross-client data leak via two distinct issues: (1) reusing a single `StreamableHTTPServerTransport` across multiple client requests, and (2) reusing a single `McpServer`/`Server` instance across multiple transports. Both are most common in stateless deployments.\n\n### Impact\n\nThis advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both.\n\n#### Issue 1: Transport re-use\n\n**What happens:** When a single `StreamableHTTPServerTransport` instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client\u0027s HTTP connection. The transport maintains an internal `requestId \u2192 stream` mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client\u0027s request overwrites the first client\u0027s mapping entry, routing the response to the wrong HTTP stream.\n\n**What is affected:** All request types \u2014 `tools/call`, `resources/read`, `prompts/get`, etc. No server-initiated features are required to trigger this.\n\n**Conditions:**\n- A single `StreamableHTTPServerTransport` instance is reused across multiple client requests (most common in stateless mode without `sessionIdGenerator`)\n- Two or more clients send requests concurrently\n- Clients generate overlapping JSON-RPC message IDs (the SDK\u0027s default client uses an incrementing counter starting at 0)\n\n#### Issue 2: Server/Protocol re-use\n\n**What happens:** When a single `McpServer` (or `Server`) instance is `connect()`ed to multiple transports (one per client), the Protocol\u0027s internal `this._transport` reference is silently overwritten. The final response to a request is routed correctly (the Protocol captures the transport reference at request time), but any **server-to-client messages sent during request handling** use the shared `this._transport` reference, which may point to a different client\u0027s transport.\n\n**What is affected:** This depends on what features your server uses:\n\n  - **Final responses** (the return value from a tool/resource/prompt handler): Affected in most cases. The Protocol captures this._transport at [request-handling time](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/core/src/shared/protocol.ts#L760), not the transport that delivered the request. This means:\n    - If a request is already in-flight when a second connect() occurs (i.e., the request\n   arrived before the transport was overwritten), the captured reference is correct and\n  the response routes properly.\n    - If a request arrives on the old transport after a second connect() has overwritten\n  this._transport, the captured reference points to the new transport, and the response\n  is mis-routed. The requesting client will time out.\n- **Progress notifications** sent during tool execution via `sendNotification`: **Affected.** These are dispatched through `this._transport`. When the transport has been overwritten and message IDs collide on the new transport, notifications are routed to the wrong client\u0027s HTTP stream.\n- **Sampling** (`createMessage`) and **elicitation** requests sent during tool execution via `sendRequest`: **Affected.** Same mechanism \u2014 the request is sent to the wrong client.\n- **Spontaneous server-initiated notifications** (outside any request handler): **Affected.** These are sent to whichever client\u0027s transport was most recently connected.\n\n**Conditions:**\n- A single `McpServer`/`Server` instance is `connect()`ed to multiple transports across requests or sessions\n- Two or more clients connect concurrently\n- For in-request notifications/requests: message ID collision on the other transport is required for silent data leaking (the SDK\u0027s default client uses an incrementing counter starting at 0). Without collision, the transport will throw an error rather than misroute.\n- For spontaneous notifications: no collision needed, messages are always sent to the last-connected client\u0027s transport\n\n#### How to tell if you\u0027re affected\n\n- **You use `sessionIdGenerator` (stateful mode) with a new `McpServer` per session** \u2192 not affected by either issue. Each session has its own transport and server instance.\n- **You use `sessionIdGenerator` but share a single `McpServer` across sessions** \u2192 not affected by Issue 1 (transport re-use), but affected by Issue 2 (server re-use) if your tools send progress notifications, sampling, or elicitation during execution.\n- **You are in stateless mode and reuse both a transport and a server across requests** \u2192 affected by both issues; all request types can leak.\n- **You are in stateless mode and create a new transport per request, but reuse the server** \u2192 affected by Issue 2 only; safe if your tools only return results without sending progress notifications, sampling, or elicitation during execution.\n- **You create a new server + transport per request** \u2192 not affected.\n- **Single-client environments** (e.g., local development with one IDE) \u2192 not affected.\n\n### Patches\n\nThe fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:\n\n1. `Protocol.connect()` now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2)\n2. Stateless `StreamableHTTPServerTransport.handleRequest()` now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1)\n3. In-flight request handler abort controllers are cleaned up on `close()`, and `sendNotification`/`sendRequest` in handler extras check the abort signal before sending, preventing messages from leaking after a transport is replaced\n\nServers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.\n\n### Workarounds\n\nIf you cannot upgrade immediately, ensure your server creates fresh `McpServer` and transport instances for each request (stateless) or session (stateful):\n\n```typescript\n// Stateless mode: create new server + transport per request\napp.post(\u0027/mcp\u0027, async (req, res) =\u003e {\n  const server = new McpServer({ name: \u0027my-server\u0027, version: \u00271.0.0\u0027 });\n  // ... register tools, resources, etc.\n  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });\n  await server.connect(transport);\n  await transport.handleRequest(req, res);\n});\n\n// Stateful mode: create new server + transport per session\nconst sessions = new Map();\napp.post(\u0027/mcp\u0027, async (req, res) =\u003e {\n  const sessionId = req.headers[\u0027mcp-session-id\u0027];\n  if (sessions.has(sessionId)) {\n    await sessions.get(sessionId).transport.handleRequest(req, res);\n  } else {\n    const server = new McpServer({ name: \u0027my-server\u0027, version: \u00271.0.0\u0027 });\n    // ... register tools, resources, etc.\n    const transport = new StreamableHTTPServerTransport({\n      sessionIdGenerator: () =\u003e randomUUID()\n    });\n    await server.connect(transport);\n    sessions.set(transport.sessionId, { server, transport });\n    await transport.handleRequest(req, res);\n  }\n});\n```",
  "id": "GHSA-345p-7cg4-v4c7",
  "modified": "2026-02-09T14:52:39Z",
  "published": "2026-02-04T20:04:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-345p-7cg4-v4c7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25536"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/issues/204"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/issues/243"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@modelcontextprotocol/sdk has cross-client data leak via shared server/transport instance reuse"
}

GHSA-3466-9Q3X-93WX

Vulnerability from github – Published: 2022-03-10 00:00 – Updated: 2022-03-17 00:02
VLAI
Details

Windows ALPC Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-23283, CVE-2022-23287.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows ALPC Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-23283, CVE-2022-23287.",
  "id": "GHSA-3466-9q3x-93wx",
  "modified": "2022-03-17T00:02:15Z",
  "published": "2022-03-10T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24505"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-24505"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-24505"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-34M3-97V7-926M

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2022-06-17 00:01
VLAI
Details

Wind River VxWorks 6.9.4 and vx7 has a Buffer Overflow in the TCP component (issue 4 of 4). There is an IPNET security vulnerability: TCP Urgent Pointer state confusion due to race condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-12263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-09T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Wind River VxWorks 6.9.4 and vx7 has a Buffer Overflow in the TCP component (issue 4 of 4). There is an IPNET security vulnerability: TCP Urgent Pointer state confusion due to race condition.",
  "id": "GHSA-34m3-97v7-926m",
  "modified": "2022-06-17T00:01:24Z",
  "published": "2022-05-24T16:53:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12263"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-189842.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-352504.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-632562.pdf"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2019-0009"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190802-0001"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K41190253"
    },
    {
      "type": "WEB",
      "url": "https://support2.windriver.com/index.php?page=cve\u0026on=view\u0026id=CVE-2019-12263"
    },
    {
      "type": "WEB",
      "url": "https://support2.windriver.com/index.php?page=security-notices"
    },
    {
      "type": "WEB",
      "url": "https://www.windriver.com/security/announcements/tcp-ip-network-stack-ipnet-urgent11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-34RW-6HRG-MXR5

Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23
VLAI
Details

A Race Condition vulnerability in Juniper Networks Junos OS LLDP implementation allows an attacker to cause LLDP to crash leading to a Denial of Service (DoS). This issue occurs when crafted LLDP packets are received by the device from an adjacent device. Multiple LACP flaps will occur after LLDP crashes. An indicator of compromise is to evaluate log file details for lldp with RLIMIT. Intervention should occur before 85% threshold of used KB versus maximum available KB memory is reached. show log messages | match RLIMIT | match lldp | last 20 Matching statement is " /kernel: %KERNEL-[number]: Process ([pid #],lldpd) has exceeded 85% of RLIMIT_DATA: " with [] as variable data to evaluate for. This issue affects: Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S15; 12.3X48 versions prior to 12.3X48-D95; 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D200; 15.1X53 versions prior to 15.1X53-D593; 16.1 versions prior to 16.1R7-S7; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R1-S9, 17.2R3-S3; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S4, 17.4R3; 18.1 versions prior to 18.1R3-S5; 18.2 versions prior to 18.2R2-S7, 18.2R3; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D33, 18.2X75-D50, 18.2X75-D420; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R2; 19.1 versions prior to 19.1R1-S4, 19.1R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-17T19:15:00Z",
    "severity": "LOW"
  },
  "details": "A Race Condition vulnerability in Juniper Networks Junos OS LLDP implementation allows an attacker to cause LLDP to crash leading to a Denial of Service (DoS). This issue occurs when crafted LLDP packets are received by the device from an adjacent device. Multiple LACP flaps will occur after LLDP crashes. An indicator of compromise is to evaluate log file details for lldp with RLIMIT. Intervention should occur before 85% threshold of used KB versus maximum available KB memory is reached. show log messages | match RLIMIT | match lldp | last 20 Matching statement is \" /kernel: %KERNEL-[number]: Process ([pid #],lldpd) has exceeded 85% of RLIMIT_DATA: \" with [] as variable data to evaluate for. This issue affects: Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S15; 12.3X48 versions prior to 12.3X48-D95; 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D200; 15.1X53 versions prior to 15.1X53-D593; 16.1 versions prior to 16.1R7-S7; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R1-S9, 17.2R3-S3; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S4, 17.4R3; 18.1 versions prior to 18.1R3-S5; 18.2 versions prior to 18.2R2-S7, 18.2R3; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D33, 18.2X75-D50, 18.2X75-D420; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R2; 19.1 versions prior to 19.1R1-S4, 19.1R2.",
  "id": "GHSA-34rw-6hrg-mxr5",
  "modified": "2022-05-24T17:23:52Z",
  "published": "2022-05-24T17:23:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1641"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11027"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-34VW-M4RH-R36P

Vulnerability from github – Published: 2022-09-16 17:17 – Updated: 2022-09-16 17:17
VLAI
Summary
Talos vulnerable dependency due to race condition in Linux kernel's IP framework XFRM
Details

Impact

A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Kubernetes workloads running in Talos are not affected since user namespaces are disabled in Talos kernel config. So an unprivileged user cannot obtain CAP_NET_ADMIN by unsharing. However untrusted workloads that run with privileged: true or having NET_ADMIN capability poses a risk.

Workarounds

Audit kubernetes workloads running in the cluster with privileged: true set or having NET_ADMIN capability and assess the threat vector.

References

  • https://nvd.nist.gov/vuln/detail/CVE-2022-3028
  • https://access.redhat.com/security/cve/CVE-2022-3028

For more information

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/talos-systems/talos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T17:17:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nA race condition was found in the Linux kernel\u0027s IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket.\n\n### Patches\nThe fix has been backported to [5.15.64](https://www.linuxkernelcves.com/cves/CVE-2022-3028) version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos \u003e= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.\n\nKubernetes workloads running in Talos are not affected since user namespaces are disabled in Talos kernel config. So an unprivileged user cannot obtain CAP_NET_ADMIN by unsharing. However untrusted workloads that run with privileged: true or having NET_ADMIN capability poses a risk.\n\n### Workarounds\nAudit kubernetes workloads running in the cluster with privileged: true set or having NET_ADMIN capability and assess the threat vector.\n\n### References\n- https://nvd.nist.gov/vuln/detail/CVE-2022-3028\n- https://access.redhat.com/security/cve/CVE-2022-3028\n\n### For more information\n- Email us at [security@siderolabs.com](mailto:security@siderolabs.com)\n",
  "id": "GHSA-34vw-m4rh-r36p",
  "modified": "2022-09-16T17:17:37Z",
  "published": "2022-09-16T17:17:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siderolabs/talos/security/advisories/GHSA-34vw-m4rh-r36p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siderolabs/talos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Talos vulnerable dependency due to race condition in Linux kernel\u0027s IP framework XFRM"
}

GHSA-34X8-RWH3-J65F

Vulnerability from github – Published: 2022-06-03 00:01 – Updated: 2022-10-18 12:00
VLAI
Details

An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-1462"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An out-of-bounds read flaw was found in the Linux kernel\u2019s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory.",
  "id": "GHSA-34x8-rwh3-j65f",
  "modified": "2022-10-18T12:00:32Z",
  "published": "2022-06-03T00:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1462"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2078466"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/oss-sec/2022/q2/155"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-34XQ-XC2C-9GXJ

Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31
VLAI
Details

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

tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.

While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:34Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.\n\nWhile reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.",
  "id": "GHSA-34xq-xc2c-9gxj",
  "modified": "2025-03-10T21:31:11Z",
  "published": "2025-03-10T21:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49594"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/033963b220633ed1602d458e7e4ac06afa9fefb2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e92d4423615a5257d0d871fc067aa561f597deb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc36c37f5fe066c4708e623ead96dc8f57224bf5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d5bece4df6090395f891110ef52a6f82d16685db"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e2ecbf3f0aa88277d43908c53b99399d55729ff9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
  • Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Mitigation
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Mitigation
Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.