Common Weakness Enumeration

CWE-362

Allowed-with-Review

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

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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.

2900 vulnerabilities reference this CWE, most recent first.

GHSA-38QW-V9Q4-HM9J

Vulnerability from github – Published: 2024-08-22 06:30 – Updated: 2024-08-23 03:30
VLAI
Details

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

configfs: fix a race in configfs_{,un}register_subsystem()

When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic.

One of cases is: A --> B --> C --> D A <-- B <-- C <-- D

 delete list_head *B        |      delete list_head *C

--------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next

Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48931"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-22T04:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs: fix a race in configfs_{,un}register_subsystem()\n\nWhen configfs_register_subsystem() or configfs_unregister_subsystem()\nis executing link_group() or unlink_group(),\nit is possible that two processes add or delete list concurrently.\nSome unfortunate interleavings of them can cause kernel panic.\n\nOne of cases is:\nA --\u003e B --\u003e C --\u003e D\nA \u003c-- B \u003c-- C \u003c-- D\n\n     delete list_head *B        |      delete list_head *C\n--------------------------------|-----------------------------------\nconfigfs_unregister_subsystem   |   configfs_unregister_subsystem\n  unlink_group                  |     unlink_group\n    unlink_obj                  |       unlink_obj\n      list_del_init             |         list_del_init\n        __list_del_entry        |           __list_del_entry\n          __list_del            |             __list_del\n            // next == C        |\n            next-\u003eprev = prev   |\n                                |               next-\u003eprev = prev\n            prev-\u003enext = next   |\n                                |                 // prev == B\n                                |                 prev-\u003enext = next\n\nFix this by adding mutex when calling link_group() or unlink_group(),\nbut parent configfs_subsystem is NULL when config_item is root.\nSo I create a mutex configfs_subsystem_mutex.",
  "id": "GHSA-38qw-v9q4-hm9j",
  "modified": "2024-08-23T03:30:59Z",
  "published": "2024-08-22T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48931"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3aadfd46858b1f64d4d6a0654b863e21aabff975"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/84ec758fb2daa236026506868c8796b0500c047d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc"
    }
  ],
  "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-392F-F2J5-97QM

Vulnerability from github – Published: 2026-07-08 15:32 – Updated: 2026-07-08 15:32
VLAI
Details

FreeRDP before 3.22.0 contains a use-after-free vulnerability in dvcman_channel_close and dvcman_call_on_receive due to improper synchronization of channel_callback access. A malicious RDP server can trigger a race condition by sending DYNVC_DATA and DYNVC_CLOSE messages concurrently, causing heap-use-after-free in the drdynvc client thread and potentially enabling remote code execution or denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56297"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T14:17:16Z",
    "severity": "HIGH"
  },
  "details": "FreeRDP before 3.22.0 contains a use-after-free vulnerability in dvcman_channel_close and dvcman_call_on_receive due to improper synchronization of channel_callback access. A malicious RDP server can trigger a race condition by sending DYNVC_DATA and DYNVC_CLOSE messages concurrently, causing heap-use-after-free in the drdynvc client thread and potentially enabling remote code execution or denial of service.",
  "id": "GHSA-392f-f2j5-97qm",
  "modified": "2026-07-08T15:32:00Z",
  "published": "2026-07-08T15:32:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-3mv2-5q57-2v8h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56297"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/freerdp-use-after-free-via-race-condition-in-drdynvc-channel-callback"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/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-392P-2Q2V-4372

Vulnerability from github – Published: 2026-07-07 20:55 – Updated: 2026-07-07 20:55
VLAI
Summary
Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption
Details

Am I affected?

Users are affected if all of the following are true:

  • Their project depends on @better-auth/oauth-provider at a version >= 1.6.0, < 1.6.11, or uses the embedded plugin in better-auth >= 1.4.8-beta.7, < 1.6.0.
  • At least one OAuth client served by their application's authorization server requests the offline_access scope, so refresh tokens are minted.
  • Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refresh token times two requests, or a service worker queues offline requests.

If developer applications do not request offline_access for any client, no refresh tokens are minted and they are not exposed.

Fix:

  1. Upgrade to @better-auth/oauth-provider@1.6.11 or later.
  2. If developers cannot upgrade, see workarounds below.

Summary

The OAuth provider's POST /oauth2/token endpoint, on the refresh_token grant, performs a non-atomic read / validate / revoke / mint sequence on the oauthRefreshToken row. Two concurrent requests presenting the same parent refresh token both pass the revocation check before either revoke completes, so each mints a fresh refresh token. The replay-detection branch only fires when revoked is already truthy at read time, which is exactly the state concurrent attackers race past. The result is a forked refresh-token family from a single parent token.

Details

The adapter.update predicate on the parent row is keyed on id only; it does not include revoked IS NULL, so two concurrent updates both succeed (last-write-wins, no error path). The schema does not declare unique on oauthRefreshToken.token, so concurrent creates do not collide on a unique-key violation either.

RFC 9700 §4.14 (OAuth Security Best Current Practice) prescribes refresh-token family invalidation on detected reuse; this implementation tries to enforce that contract through the revoked check, but the check is not atomic with the consumption step. Token rotation issues a new refresh token with each call, so a single stolen refresh token grants indefinite access until the row is revoked or its refreshTokenExpiresAt (default 7 days) passes. Rotation refreshes that window each call.

The fix lands an atomic compare-and-swap on the parent row inside the rotation primitive (UPDATE ... WHERE id = ? AND revoked IS NULL with a rowcount check), so the losing rotation fails closed with invalid_grant and the parent row stays marked revoked. Subsequent replay of the original refresh token then trips the existing family-invalidation guard. The schema gains a unique constraint on oauthRefreshToken.token for parity with oauthAccessToken.token.

Patches

Fixed in @better-auth/oauth-provider@1.6.11. The refresh-token rotation primitive now performs an atomic compare-and-swap on the parent row, and the explicit revokeRefreshToken path uses the same CAS. On a contested rotation, exactly one caller wins and mints a fresh refresh token; the loser receives invalid_grant. Subsequent replay of the original refresh token trips the existing family-invalidation guard because the parent row stays marked revoked.

@better-auth/memory-adapter@1.6.11 ships a compatibility fix in the same wave: the in-memory where clause now treats undefined and null as equivalent under an eq null predicate, mirroring SQL IS NULL and Mongo's missing-or-null semantics. Without this change, the CAS predicate WHERE revoked IS NULL falls through on every call against a row whose optional revoked field is absent (the adapter factory's transformInput skips writing undefined when no default exists), so the rotation above is broken for any deployment using the in-memory adapter.

Strict refresh-token family invalidation on a contested rotation, per RFC 9700 §4.14 (which calls for invalidating the winner's tokens too when reuse is detected at rotation time), is deferred to a follow-up minor on the next channel. Closing it cleanly requires an opt-in transactional rotation in the adapter contract so the family-delete cannot interleave with the winner's in-flight access-token insert. The deferred site carries a FIXME(strict-family-invalidation) marker.

Schema-migration note: the better-auth migration generator only emits UNIQUE for newly-created columns. Existing installs will not pick up the new oauthRefreshToken.token unique constraint from migrate / generate; add it manually if an application's operational tooling depends on it (CREATE UNIQUE INDEX oauth_refresh_token_token_uniq ON "oauthRefreshToken" (token);). The CAS fix above does not depend on the database-level constraint to be correct; the constraint is defense-in-depth so collisions from a buggy custom generateRefreshToken callback fail loudly.

Workarounds

None of these close the bug fully without a code patch.

  • Adapter-level: configure the database adapter to run the OAuth refresh handler under serializable isolation, or wrap the adapter.update on oauthRefreshToken with a row-level pessimistic lock (SELECT ... FOR UPDATE). Narrows the window without closing it.
  • Token lifetime: pass oauthProvider({ refreshTokenExpiresIn: 60 }) to expire forked families within one minute. Trades attacker persistence for shorter user sessions.
  • Client-side single-flight: serialize refresh-token usage in the client SDK with a mutex. Mitigates honest concurrency but does nothing against an attacker with a stolen refresh token.
  • Disable refresh tokens: do not request the offline_access scope. Closes the surface but breaks long-lived sessions.

Impact

  • Indefinite access from a single stolen refresh token: forked refresh-token families grant access at the original user's authorization scope, surviving past any single revocation if an attacker holds any branch.
  • Detection bypass: legitimate users whose refresh token has been forked do not trip family invalidation when they refresh, because the attacker's branch already swapped the parent row out from under the legitimate user's check.

Credit

Reported by @chdanielmueller.

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/oauth-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.8-beta.7"
            },
            {
              "fixed": "1.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-362",
      "CWE-367",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:55:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their project depends on `@better-auth/oauth-provider` at a version `\u003e= 1.6.0, \u003c 1.6.11`, or uses the embedded plugin in `better-auth \u003e= 1.4.8-beta.7, \u003c 1.6.0`.\n- At least one OAuth client served by their application\u0027s authorization server requests the `offline_access` scope, so refresh tokens are minted.\n- Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refresh token times two requests, or a service worker queues offline requests.\n\nIf developer applications do not request `offline_access` for any client, no refresh tokens are minted and they are not exposed.\n\nFix:\n\n1. Upgrade to `@better-auth/oauth-provider@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe OAuth provider\u0027s `POST /oauth2/token` endpoint, on the `refresh_token` grant, performs a non-atomic read / validate / revoke / mint sequence on the `oauthRefreshToken` row. Two concurrent requests presenting the same parent refresh token both pass the revocation check before either revoke completes, so each mints a fresh refresh token. The replay-detection branch only fires when `revoked` is already truthy at read time, which is exactly the state concurrent attackers race past. The result is a forked refresh-token family from a single parent token.\n\n### Details\n\nThe `adapter.update` predicate on the parent row is keyed on `id` only; it does not include `revoked IS NULL`, so two concurrent updates both succeed (last-write-wins, no error path). The schema does not declare `unique` on `oauthRefreshToken.token`, so concurrent creates do not collide on a unique-key violation either.\n\nRFC 9700 \u00a74.14 (OAuth Security Best Current Practice) prescribes refresh-token family invalidation on detected reuse; this implementation tries to enforce that contract through the `revoked` check, but the check is not atomic with the consumption step. Token rotation issues a new refresh token with each call, so a single stolen refresh token grants indefinite access until the row is revoked or its `refreshTokenExpiresAt` (default 7 days) passes. Rotation refreshes that window each call.\n\nThe fix lands an atomic compare-and-swap on the parent row inside the rotation primitive (`UPDATE ... WHERE id = ? AND revoked IS NULL` with a rowcount check), so the losing rotation fails closed with `invalid_grant` and the parent row stays marked revoked. Subsequent replay of the original refresh token then trips the existing family-invalidation guard. The schema gains a unique constraint on `oauthRefreshToken.token` for parity with `oauthAccessToken.token`.\n\n### Patches\n\nFixed in `@better-auth/oauth-provider@1.6.11`. The refresh-token rotation primitive now performs an atomic compare-and-swap on the parent row, and the explicit `revokeRefreshToken` path uses the same CAS. On a contested rotation, exactly one caller wins and mints a fresh refresh token; the loser receives `invalid_grant`. Subsequent replay of the original refresh token trips the existing family-invalidation guard because the parent row stays marked revoked.\n\n`@better-auth/memory-adapter@1.6.11` ships a compatibility fix in the same wave: the in-memory `where` clause now treats `undefined` and `null` as equivalent under an `eq null` predicate, mirroring SQL `IS NULL` and Mongo\u0027s missing-or-null semantics. Without this change, the CAS predicate `WHERE revoked IS NULL` falls through on every call against a row whose optional `revoked` field is absent (the adapter factory\u0027s `transformInput` skips writing `undefined` when no default exists), so the rotation above is broken for any deployment using the in-memory adapter.\n\nStrict refresh-token family invalidation on a contested rotation, per RFC 9700 \u00a74.14 (which calls for invalidating the winner\u0027s tokens too when reuse is detected at rotation time), is deferred to a follow-up minor on the `next` channel. Closing it cleanly requires an opt-in transactional rotation in the adapter contract so the family-delete cannot interleave with the winner\u0027s in-flight access-token insert. The deferred site carries a `FIXME(strict-family-invalidation)` marker.\n\nSchema-migration note: the better-auth migration generator only emits `UNIQUE` for newly-created columns. Existing installs will not pick up the new `oauthRefreshToken.token` unique constraint from `migrate` / `generate`; add it manually if an application\u0027s operational tooling depends on it (`CREATE UNIQUE INDEX oauth_refresh_token_token_uniq ON \"oauthRefreshToken\" (token);`). The CAS fix above does not depend on the database-level constraint to be correct; the constraint is defense-in-depth so collisions from a buggy custom `generateRefreshToken` callback fail loudly.\n\n### Workarounds\n\nNone of these close the bug fully without a code patch.\n\n- **Adapter-level**: configure the database adapter to run the OAuth refresh handler under serializable isolation, or wrap the `adapter.update` on `oauthRefreshToken` with a row-level pessimistic lock (`SELECT ... FOR UPDATE`). Narrows the window without closing it.\n- **Token lifetime**: pass `oauthProvider({ refreshTokenExpiresIn: 60 })` to expire forked families within one minute. Trades attacker persistence for shorter user sessions.\n- **Client-side single-flight**: serialize refresh-token usage in the client SDK with a mutex. Mitigates honest concurrency but does nothing against an attacker with a stolen refresh token.\n- **Disable refresh tokens**: do not request the `offline_access` scope. Closes the surface but breaks long-lived sessions.\n\n### Impact\n\n- **Indefinite access from a single stolen refresh token**: forked refresh-token families grant access at the original user\u0027s authorization scope, surviving past any single revocation if an attacker holds any branch.\n- **Detection bypass**: legitimate users whose refresh token has been forked do not trip family invalidation when they refresh, because the attacker\u0027s branch already swapped the parent row out from under the legitimate user\u0027s check.\n\n### Credit\n\nReported by @chdanielmueller.\n\n### Resources\n\n- [CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)](https://cwe.mitre.org/data/definitions/362.html)\n- [CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition](https://cwe.mitre.org/data/definitions/367.html)\n- [CWE-294: Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html)\n- [CWE-613: Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html)\n- [RFC 9700 \u00a74.14: Refresh Token Protection](https://datatracker.ietf.org/doc/html/rfc9700#section-4.14)\n- [RFC 6749 \u00a76: Refreshing an Access Token](https://datatracker.ietf.org/doc/html/rfc6749#section-6)",
  "id": "GHSA-392p-2q2v-4372",
  "modified": "2026-07-07T20:55:48Z",
  "published": "2026-07-07T20:55:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-392p-2q2v-4372"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption"
}

GHSA-3959-J6XJ-M4C3

Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2026-05-12 12:31
VLAI
Details

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

net/bnx2x: Prevent access to a freed page in page_pool

Fix race condition leading to system crash during EEH error handling

During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge()

799 static inline void bnx2x_free_rx_sge(struct bnx2x bp, 800 struct bnx2x_fastpath fp, u16 index) 801 { 802 struct sw_rx_page sw_buf = &fp->rx_page_ring[index]; 803 struct page page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread.

EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64

To solve this issue, we need to verify page pool allocations before freeing.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-26859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-17T11:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/bnx2x: Prevent access to a freed page in page_pool\n\nFix race condition leading to system crash during EEH error handling\n\nDuring EEH error recovery, the bnx2x driver\u0027s transmit timeout logic\ncould cause a race condition when handling reset tasks. The\nbnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),\nwhich ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()\nSGEs are freed using bnx2x_free_rx_sge_range(). However, this could\noverlap with the EEH driver\u0027s attempt to reset the device using\nbnx2x_io_slot_reset(), which also tries to free SGEs. This race\ncondition can result in system crashes due to accessing freed memory\nlocations in bnx2x_free_rx_sge()\n\n799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,\n800\t\t\t\tstruct bnx2x_fastpath *fp, u16 index)\n801  {\n802\tstruct sw_rx_page *sw_buf = \u0026fp-\u003erx_page_ring[index];\n803     struct page *page = sw_buf-\u003epage;\n....\nwhere sw_buf was set to NULL after the call to dma_unmap_page()\nby the preceding thread.\n\n    EEH: Beginning: \u0027slot_reset\u0027\n    PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-\u003eslot_reset()\n    bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...\n    bnx2x 0011:01:00.0: enabling device (0140 -\u003e 0142)\n    bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --\u003e driver unload\n    Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n    BUG: Kernel NULL pointer dereference on read at 0x00000000\n    Faulting instruction address: 0xc0080000025065fc\n    Oops: Kernel access of bad area, sig: 11 [#1]\n    .....\n    Call Trace:\n    [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)\n    [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0\n    [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550\n    [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60\n    [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170\n    [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0\n    [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\nTo solve this issue, we need to verify page pool allocations before\nfreeing.",
  "id": "GHSA-3959-j6xj-m4c3",
  "modified": "2026-05-12T12:31:37Z",
  "published": "2024-04-17T12:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26859"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/44f9f1abb0ecc43023225ab9539167facbabf0ec"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2df3fc68"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d27e2da94a42655861ca4baea30c8cd65546f25d"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "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-39CX-99PJ-4MQG

Vulnerability from github – Published: 2023-07-06 15:30 – Updated: 2024-04-04 05:26
VLAI
Details

Race condition vulnerability due to multi-thread access to mutually exclusive resources in Huawei Share. Successful exploitation of this vulnerability may cause the program to exit abnormally.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-06T13:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Race condition vulnerability due to multi-thread access to mutually exclusive resources in Huawei Share. Successful exploitation of this vulnerability may cause the program to exit abnormally.",
  "id": "GHSA-39cx-99pj-4mqg",
  "modified": "2024-04-04T05:26:03Z",
  "published": "2023-07-06T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48509"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/7"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202307-0000001587168858"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-39XG-8P43-H76X

Vulnerability from github – Published: 2021-08-25 20:51 – Updated: 2023-06-13 20:28
VLAI
Summary
Data races in reffers
Details

ARefss<'a, V> is a type that is assumed to contain objects that are Send + Sync.

In the affected versions of this crate, Send/Sync traits are unconditionally implemented for ARefss<'a, V>.

By using the ARefss::map() API, we can insert a !Send or !Sync object into ARefss<'a, V>. After that, it is possible to create a data race to the inner object of ARefss<'a, V>, which can lead to undefined behavior & memory corruption.

The flaw was corrected in commit 6dd7ca0 by adding trait bound V: Send + Sync to ARefss::map() API.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "reffers"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T18:49:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "ARefss\u003c\u0027a, V\u003e is a type that is assumed to contain objects that are Send + Sync.\n\nIn the affected versions of this crate, Send/Sync traits are unconditionally implemented for ARefss\u003c\u0027a, V\u003e.\n\nBy using the ARefss::map() API, we can insert a !Send or !Sync object into ARefss\u003c\u0027a, V\u003e. After that, it is possible to create a data race to the inner object of ARefss\u003c\u0027a, V\u003e, which can lead to undefined behavior \u0026 memory corruption.\n\nThe flaw was corrected in commit `6dd7ca0` by adding trait bound V: Send + Sync to ARefss::map() API.",
  "id": "GHSA-39xg-8p43-h76x",
  "modified": "2023-06-13T20:28:35Z",
  "published": "2021-08-25T20:51:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/diwic/reffers-rs/issues/7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/diwic/reffers-rs/commit/6dd7ca0d50f2464df708975cdafcfaeeb6d41c66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/diwic/reffers-rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0094.html"
    }
  ],
  "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"
    }
  ],
  "summary": "Data races in reffers"
}

GHSA-3C9M-2JJ9-HX36

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:

cipso: Fix data-races around sysctl.

While reading cipso sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-49639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncipso: Fix data-races around sysctl.\n\nWhile reading cipso sysctl variables, they can be changed concurrently.\nSo, we need to add READ_ONCE() to avoid data-races.",
  "id": "GHSA-3c9m-2jj9-hx36",
  "modified": "2025-03-12T00:31:48Z",
  "published": "2025-03-12T00:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49639"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07b0caf8aeb9b82e6ecc6c292a3e47c7fcdb1148"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e41a0f73ccb9be112a80bde3804a771633caaef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2764f82bbc158d106693ae3ced3675cf4b963b35"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/59e26906b89cc35bb54476498772b45cbc32323f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c321e99d2725d11f7e6a4ebd9ce752259f0bae81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca26ca5e2f3eeb3e6fe699cd6effa3b4b2aa8698"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd44f04b9214adb68ef5684ae87a81ba03632250"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe2a35fa2c4f9c8ce5ef970eb927031387f9446a"
    }
  ],
  "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-3CGF-9M6X-PWWR

Vulnerability from github – Published: 2021-08-25 20:47 – Updated: 2021-08-19 21:08
VLAI
Summary
Data races in rusqlite
Details

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via UnlockNotification.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rusqlite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-35868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T21:08:22Z",
    "nvd_published_at": "2020-12-31T10:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via UnlockNotification.",
  "id": "GHSA-3cgf-9m6x-pwwr",
  "modified": "2021-08-19T21:08:22Z",
  "published": "2021-08-25T20:47:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rusqlite/rusqlite/commit/45fd77ee43c38eea4d6f4e2e56c1667a55ec654f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rusqlite/rusqlite"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rusqlite/rusqlite/releases/tag/0.23.0"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0014.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data races in rusqlite"
}

GHSA-3CP5-5CQ5-76JP

Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-06 00:00
VLAI
Details

In audio ipi, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06478101; Issue ID: ALPS06478101.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-21789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-01T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In audio ipi, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06478101; Issue ID: ALPS06478101.",
  "id": "GHSA-3cp5-5cq5-76jp",
  "modified": "2022-08-06T00:00:54Z",
  "published": "2022-08-02T00:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21789"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/August-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3CWH-5R3X-FM73

Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Hyper-V allows an authorized attacker to elevate privileges locally.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-55328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T17:15:45Z",
    "severity": "HIGH"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Hyper-V allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-3cwh-5r3x-fm73",
  "modified": "2025-10-14T18:30:30Z",
  "published": "2025-10-14T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55328"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55328"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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.

← Back to the CWE list