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.

2901 vulnerabilities reference this CWE, most recent first.

GHSA-6R57-P65P-MF3Q

Vulnerability from github – Published: 2022-05-01 23:27 – Updated: 2022-05-01 23:27
VLAI
Details

Foundation in Apple Mac OS X 10.4.11 creates world-writable directories while NSFileManager copies files recursively and only modifies the permissions afterward, which allows local users to modify copied files to cause a denial of service and possibly gain privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2008-0055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-03-18T23:44:00Z",
    "severity": "HIGH"
  },
  "details": "Foundation in Apple Mac OS X 10.4.11 creates world-writable directories while NSFileManager copies files recursively and only modifies the permissions afterward, which allows local users to modify copied files to cause a denial of service and possibly gain privileges.",
  "id": "GHSA-6r57-p65p-mf3q",
  "modified": "2022-05-01T23:27:24Z",
  "published": "2022-05-01T23:27:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0055"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41299"
    },
    {
      "type": "WEB",
      "url": "http://docs.info.apple.com/article.html?artnum=307562"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2008/Mar/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29420"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28304"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28343"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1019649"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA08-079A.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/0924/references"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6R89-47F8-29J3

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

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

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T18:15:36Z",
    "severity": "HIGH"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Speech allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-6r89-47f8-29j3",
  "modified": "2025-11-11T18:30:20Z",
  "published": "2025-11-11T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59508"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59508"
    }
  ],
  "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-6R96-PJ86-R49G

Vulnerability from github – Published: 2025-11-28 03:30 – Updated: 2025-11-28 03:30
VLAI
Details

UAF vulnerability in the screen recording framework module. Impact: Successful exploitation of this vulnerability may affect availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-58303"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-28T03:15:59Z",
    "severity": "HIGH"
  },
  "details": "UAF vulnerability in the screen recording framework module.\nImpact: Successful exploitation of this vulnerability may affect availability.",
  "id": "GHSA-6r96-pj86-r49g",
  "modified": "2025-11-28T03:30:26Z",
  "published": "2025-11-28T03:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58303"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6R9H-3C6P-4CHM

Vulnerability from github – Published: 2026-02-11 21:30 – Updated: 2026-02-12 18:30
VLAI
Details

A race condition vulnerability exists in MedusaJS Medusa v2.12.2 and earlier in the registerUsage() function of the promotion module. The function performs a non-atomic read-check-update operation when enforcing promotion usage limits. This allows unauthenticated remote attackers to bypass usage limits by sending concurrent checkout requests, resulting in unlimited redemptions of limited-use promotional codes and potential financial loss.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-69871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-11T19:15:50Z",
    "severity": "HIGH"
  },
  "details": "A race condition vulnerability exists in MedusaJS Medusa v2.12.2 and earlier in the registerUsage() function of the promotion module. The function performs a non-atomic read-check-update operation when enforcing promotion usage limits. This allows unauthenticated remote attackers to bypass usage limits by sending concurrent checkout requests, resulting in unlimited redemptions of limited-use promotional codes and potential financial loss.",
  "id": "GHSA-6r9h-3c6p-4chm",
  "modified": "2026-02-12T18:30:21Z",
  "published": "2026-02-11T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69871"
    },
    {
      "type": "WEB",
      "url": "https://github.com/medusajs/medusa/pull/13760"
    },
    {
      "type": "WEB",
      "url": "https://github.com/EthanKim88/ethan-cve-disclosures/blob/main/CVE-2025-69871-MedusaJS-TOCTOU.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/medusajs/medusa"
    }
  ],
  "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-6RC5-MH5G-63WM

Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-10-28 18:30
VLAI
Details

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

mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups

In commit 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none():

-       if (!pmd_present(pmde))
-               return SCAN_PMD_NULL;
+       if (pmd_none(pmde))
+               return SCAN_PMD_NONE;

This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd. Such codepaths include:

A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER already in the pagecache. B) In retract_page_tables(), if we fail to grab mmap_lock for the target mm/address.

In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.

However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds. One such example that could leak through are swap entries. The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd.

We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch.

The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state. For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit.

Covering all 4 cases for x86 (all checks done on the same pmd value):

1) pmd_present() && pmd_trans_huge() All we actually know here is that the PSE bit is set. Either: a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE is set. => huge-pmd b) We are currently racing with __split_huge_page(). The danger here is that we proceed as-if we have a huge-pmd, but really we are looking at a pte-mapping-pmd. So, what is the risk of this danger?

  The only relevant path is:

madvise_collapse() -> collapse_pte_mapped_thp()

  Where we might just incorrectly report back "success", when really
  the memory isn't pmd-backed.  This is fine, since split could
  happen immediately after (actually) successful madvise_collapse().
  So, it should be safe to just assume huge-pmd here.

2) pmd_present() && !pmd_trans_huge() Either: a) PSE not set and either PRESENT or PROTNONE is. => pte-table-mapping pmd (or PROT_NONE) b) devmap. This routine can be called immediately after unlocking/locking mmap_lock -- or called with no locks held (see khugepaged_scan_mm_slot()), so previous VMA checks have since been invalidated.

3) !pmd_present() && pmd_trans_huge() Not possible.

4) !pmd_present() && !pmd_trans_huge() Neither PRESENT nor PROTNONE set => not present

I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path).

Also, add a comment above find_pmd_or_thp_or_none() ---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52934"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T17:15:43Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups\n\nIn commit 34488399fa08 (\"mm/madvise: add file and shmem support to\nMADV_COLLAPSE\") we make the following change to find_pmd_or_thp_or_none():\n\n\t-       if (!pmd_present(pmde))\n\t-               return SCAN_PMD_NULL;\n\t+       if (pmd_none(pmde))\n\t+               return SCAN_PMD_NONE;\n\nThis was for-use by MADV_COLLAPSE file/shmem codepaths, where\nMADV_COLLAPSE might identify a pte-mapped hugepage, only to have\nkhugepaged race-in, free the pte table, and clear the pmd.  Such codepaths\ninclude:\n\nA) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER\n   already in the pagecache.\nB) In retract_page_tables(), if we fail to grab mmap_lock for the target\n   mm/address.\n\nIn these cases, collapse_pte_mapped_thp() really does expect a none (not\njust !present) pmd, and we want to suitably identify that case separate\nfrom the case where no pmd is found, or it\u0027s a bad-pmd (of course, many\nthings could happen once we drop mmap_lock, and the pmd could plausibly\nundergo multiple transitions due to intervening fault, split, etc). \nRegardless, the code is prepared install a huge-pmd only when the existing\npmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.\n\nHowever, the commit introduces a logical hole; namely, that we\u0027ve allowed\n!none- \u0026\u0026 !huge- \u0026\u0026 !bad-pmds to be classified as genuine\npte-table-mapping-pmds.  One such example that could leak through are swap\nentries.  The pmd values aren\u0027t checked again before use in\npte_offset_map_lock(), which is expecting nothing less than a genuine\npte-table-mapping-pmd.\n\nWe want to put back the !pmd_present() check (below the pmd_none() check),\nbut need to be careful to deal with subtleties in pmd transitions and\ntreatments by various arch.\n\nThe issue is that __split_huge_pmd_locked() temporarily clears the present\nbit (or otherwise marks the entry as invalid), but pmd_present() and\npmd_trans_huge() still need to return true while the pmd is in this\ntransitory state.  For example, x86\u0027s pmd_present() also checks the\n_PAGE_PSE , riscv\u0027s version also checks the _PAGE_LEAF bit, and arm64 also\nchecks a PMD_PRESENT_INVALID bit.\n\nCovering all 4 cases for x86 (all checks done on the same pmd value):\n\n1) pmd_present() \u0026\u0026 pmd_trans_huge()\n   All we actually know here is that the PSE bit is set. Either:\n   a) We aren\u0027t racing with __split_huge_page(), and PRESENT or PROTNONE\n      is set.\n      =\u003e huge-pmd\n   b) We are currently racing with __split_huge_page().  The danger here\n      is that we proceed as-if we have a huge-pmd, but really we are\n      looking at a pte-mapping-pmd.  So, what is the risk of this\n      danger?\n\n      The only relevant path is:\n\n\tmadvise_collapse() -\u003e collapse_pte_mapped_thp()\n\n      Where we might just incorrectly report back \"success\", when really\n      the memory isn\u0027t pmd-backed.  This is fine, since split could\n      happen immediately after (actually) successful madvise_collapse().\n      So, it should be safe to just assume huge-pmd here.\n\n2) pmd_present() \u0026\u0026 !pmd_trans_huge()\n   Either:\n   a) PSE not set and either PRESENT or PROTNONE is.\n      =\u003e pte-table-mapping pmd (or PROT_NONE)\n   b) devmap.  This routine can be called immediately after\n      unlocking/locking mmap_lock -- or called with no locks held (see\n      khugepaged_scan_mm_slot()), so previous VMA checks have since been\n      invalidated.\n\n3) !pmd_present() \u0026\u0026 pmd_trans_huge()\n  Not possible.\n\n4) !pmd_present() \u0026\u0026 !pmd_trans_huge()\n  Neither PRESENT nor PROTNONE set\n  =\u003e not present\n\nI\u0027ve checked all archs that implement pmd_trans_huge() (arm64, riscv,\npowerpc, longarch, x86, mips, s390) and this logic roughly translates\n(though devmap treatment is unique to x86 and powerpc, and (3) doesn\u0027t\nnecessarily hold in general -- but that doesn\u0027t matter since\n!pmd_present() always takes failure path).\n\nAlso, add a comment above find_pmd_or_thp_or_none()\n---truncated---",
  "id": "GHSA-6rc5-mh5g-63wm",
  "modified": "2025-10-28T18:30:23Z",
  "published": "2025-03-27T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52934"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96aaaf8666010a39430cecf8a65c7ce2908a030f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edb5d0cf5525357652aff6eacd9850b8ced07143"
    }
  ],
  "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-6RCH-H7PJ-5838

Vulnerability from github – Published: 2022-04-29 03:01 – Updated: 2025-04-03 04:05
VLAI
Details

A race condition in Opera web browser 7.53 Build 3850 causes Opera to fill in the address bar before the page has been loaded, which allows remote attackers to spoof the URL in the address bar via the window.open and location.replace HTML parameters, which facilitates phishing attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2004-2491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-12-31T05:00:00Z",
    "severity": "LOW"
  },
  "details": "A race condition in Opera web browser 7.53 Build 3850 causes Opera to fill in the address bar before the page has been loaded, which allows remote attackers to spoof the URL in the address bar via the window.open and location.replace HTML parameters, which facilitates phishing attacks.",
  "id": "GHSA-6rch-h7pj-5838",
  "modified": "2025-04-03T04:05:43Z",
  "published": "2022-04-29T03:01:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2491"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/16816"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2004-07/1056.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/12162"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/windows/changelogs/754"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/8317"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/10810"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6RRC-VWRV-CWXC

Vulnerability from github – Published: 2025-04-15 15:30 – Updated: 2025-04-18 15:31
VLAI
Details

A race condition existed in nsHttpTransaction that could have been exploited to cause memory corruption, potentially leading to an exploitable condition. This vulnerability affects Firefox < 137.0.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-15T13:15:55Z",
    "severity": "MODERATE"
  },
  "details": "A race condition existed in nsHttpTransaction that could have been exploited to cause memory corruption, potentially leading to an exploitable condition. This vulnerability affects Firefox \u003c 137.0.2.",
  "id": "GHSA-6rrc-vwrv-cwxc",
  "modified": "2025-04-18T15:31:36Z",
  "published": "2025-04-15T15:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3608"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1951554"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-3608"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-25"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6RWQ-388V-8MMP

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

In memory management driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185196177

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-0532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-21T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "In memory management driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185196177",
  "id": "GHSA-6rwq-388v-8mmp",
  "modified": "2022-05-24T19:05:42Z",
  "published": "2022-05-24T19:05:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0532"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2021-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6V24-6WGF-8VJ6

Vulnerability from github – Published: 2025-05-24 03:30 – Updated: 2025-05-27 18:04
VLAI
Summary
process_lock has a Potential Unsound issue in unlock
Details

The process_lock crate 0.1.0 for Rust allows data races in unlock.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "process_lock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-27T18:04:07Z",
    "nvd_published_at": "2025-05-24T03:15:23Z",
    "severity": "LOW"
  },
  "details": "The process_lock crate 0.1.0 for Rust allows data races in unlock.",
  "id": "GHSA-6v24-6wgf-8vj6",
  "modified": "2025-05-27T18:04:08Z",
  "published": "2025-05-24T03:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48751"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tickbh/ProcessLock/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/process_lock"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tickbh/ProcessLock"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "process_lock has a Potential Unsound issue in unlock"
}

GHSA-6V28-56J9-QH5Q

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31
VLAI
Details

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

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:15:52Z",
    "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-6v28-56j9-qh5q",
  "modified": "2025-09-09T18:31:20Z",
  "published": "2025-09-09T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54092"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54092"
    }
  ],
  "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.