CWE-362
Allowed-with-ReviewConcurrent 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.
2903 vulnerabilities reference this CWE, most recent first.
GHSA-4VGR-H27G-CF9P
Vulnerability from github – Published: 2026-07-01 20:02 – Updated: 2026-07-01 20:02The HTTP /rpc endpoint has a time-of-check/time-of-use (TOCTOU) race condition on internal session state. When authenticated and unauthenticated requests are processed concurrently, the unauthenticated request can inherit the authenticated user's session and privileges. The /rpc endpoint is the primary interface used by all official SurrealDB SDKs.
The HTTP /rpc handler does not bind each incoming request to an isolated session context. Instead, concurrent requests share mutable authentication state. When an authenticated request sets the session context and an unauthenticated request races in before it is cleared, the unauthenticated request executes with the authenticated user's privileges.
The impact depends on the privilege level of the session that is hijacked. If a root or namespace-level user session is inherited, the attacker can read and modify any data, delete records, and create persistent namespace-level users. If a scoped record user session is inherited, the attacker is limited to that user's permissions.
The attack requires no credentials, tokens, or session knowledge — only the ability to send concurrent HTTP requests to the /rpc endpoint while legitimate authenticated traffic is active.
Impact
An unauthenticated attacker who can reach the /rpc endpoint can escalate privileges by racing against any active authenticated session. The severity of the impact depends on the permissions of the user whose session was hijacked. This could include escalation to root user of SurrealDB instance
Patches
Versions prior to SurrealDB v3.1.0 are vulnerable.
A patch has been introduced that replaces the shared default session with per-request session isolation. Every POST /rpc request now allocates a fresh, server-side UUID and runs entirely within that session's scope for the duration of the request. The session-map signatures across the RPC protocol have been changed from Option<Uuid> to Uuid so the "default session" can no longer be represented at the type level, preventing future regressions of the same shape.
Workarounds
There is no configuration-level mitigation that fully addresses this vulnerability. Network-level controls restricting access to the /rpc endpoint to trusted clients can reduce exposure.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:02:06Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The HTTP `/rpc` endpoint has a time-of-check/time-of-use (TOCTOU) race condition on internal session state. When authenticated and unauthenticated requests are processed concurrently, the unauthenticated request can inherit the authenticated user\u0027s session and privileges. The `/rpc` endpoint is the primary interface used by all official SurrealDB SDKs.\n\nThe HTTP `/rpc` handler does not bind each incoming request to an isolated session context. Instead, concurrent requests share mutable authentication state. When an authenticated request sets the session context and an unauthenticated request races in before it is cleared, the unauthenticated request executes with the authenticated user\u0027s privileges.\n\nThe impact depends on the privilege level of the session that is hijacked. If a root or namespace-level user session is inherited, the attacker can read and modify any data, delete records, and create persistent namespace-level users. If a scoped record user session is inherited, the attacker is limited to that user\u0027s permissions.\n\nThe attack requires no credentials, tokens, or session knowledge \u2014 only the ability to send concurrent HTTP requests to the `/rpc` endpoint while legitimate authenticated traffic is active.\n\n## Impact\n\nAn unauthenticated attacker who can reach the `/rpc` endpoint can escalate privileges by racing against any active authenticated session. The severity of the impact depends on the permissions of the user whose session was hijacked. This could include escalation to root user of SurrealDB instance\n\n## Patches\n\nVersions prior to SurrealDB `v3.1.0` are vulnerable.\n\nA patch has been introduced that replaces the shared default session with per-request session isolation. Every `POST /rpc` request now allocates a fresh, server-side UUID and runs entirely within that session\u0027s scope for the duration of the request. The session-map signatures across the RPC protocol have been changed from `Option\u003cUuid\u003e` to `Uuid` so the \"default session\" can no longer be represented at the type level, preventing future regressions of the same shape.\n\n## Workarounds\n\nThere is no configuration-level mitigation that fully addresses this vulnerability. Network-level controls restricting access to the `/rpc` endpoint to trusted clients can reduce exposure.",
"id": "GHSA-4vgr-h27g-cf9p",
"modified": "2026-07-01T20:02:06Z",
"published": "2026-07-01T20:02:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-4vgr-h27g-cf9p"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/commit/2f53e6e86d1b87e38300e714cfd7aede1abe4c3d"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/commit/fd800fc7c55afcdc97057d18cf7cb7f83557e702"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"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"
}
],
"summary": "SurrealDB: HTTP RPC Session Race Condition Allows Privilege Escalation"
}
GHSA-4VJW-GHVR-GV6W
Vulnerability from github – Published: 2022-06-18 00:00 – Updated: 2022-07-01 00:01Versions of the Amazon AWS Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.3.5 are affected by a race condition that could lead to a local privilege escalation. This Hotpatch package is not a replacement for updating to a log4j version that mitigates CVE-2021-44228 or CVE-2021-45046; it provides a temporary mitigation to CVE-2021-44228 by hotpatching the local Java virtual machines. To do so, it iterates through all running Java processes, performs several checks, and executes the Java virtual machine with the same permissions and capabilities as the running process to load the hotpatch. A local user could cause the hotpatch script to execute a binary with elevated privileges by running a custom java process that performs exec() of an SUID binary after the hotpatch has observed the process path and before it has observed its effective user ID.
{
"affected": [],
"aliases": [
"CVE-2022-33915"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-17T13:15:00Z",
"severity": "HIGH"
},
"details": "Versions of the Amazon AWS Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.3.5 are affected by a race condition that could lead to a local privilege escalation. This Hotpatch package is not a replacement for updating to a log4j version that mitigates CVE-2021-44228 or CVE-2021-45046; it provides a temporary mitigation to CVE-2021-44228 by hotpatching the local Java virtual machines. To do so, it iterates through all running Java processes, performs several checks, and executes the Java virtual machine with the same permissions and capabilities as the running process to load the hotpatch. A local user could cause the hotpatch script to execute a binary with elevated privileges by running a custom java process that performs exec() of an SUID binary after the hotpatch has observed the process path and before it has observed its effective user ID.",
"id": "GHSA-4vjw-ghvr-gv6w",
"modified": "2022-07-01T00:01:06Z",
"published": "2022-06-18T00:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33915"
},
{
"type": "WEB",
"url": "https://alas.aws.amazon.com/AL2/ALAS-2022-1806.html"
},
{
"type": "WEB",
"url": "https://alas.aws.amazon.com/ALAS-2022-1601.html"
}
],
"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-4VMW-3CP6-84QX
Vulnerability from github – Published: 2023-04-11 21:30 – Updated: 2023-04-11 21:30Windows DNS Server Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-28307"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-11T21:15:00Z",
"severity": "MODERATE"
},
"details": "Windows DNS Server Remote Code Execution Vulnerability",
"id": "GHSA-4vmw-3cp6-84qx",
"modified": "2023-04-11T21:30:58Z",
"published": "2023-04-11T21:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28307"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28307"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4VR2-36WR-V82R
Vulnerability from github – Published: 2022-05-17 02:16 – Updated: 2022-05-17 02:16VMware Tools prior to 10.0.9 contains multiple file system races in libDeployPkg, related to the use of hard-coded paths under /tmp. Successful exploitation of this issue may result in a local privilege escalation. CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
{
"affected": [],
"aliases": [
"CVE-2015-5191"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-28T21:29:00Z",
"severity": "MODERATE"
},
"details": "VMware Tools prior to 10.0.9 contains multiple file system races in libDeployPkg, related to the use of hard-coded paths under /tmp. Successful exploitation of this issue may result in a local privilege escalation. CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"id": "GHSA-4vr2-36wr-v82r",
"modified": "2022-05-17T02:16:02Z",
"published": "2022-05-17T02:16:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5191"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2017-0013.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100011"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039013"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4W59-2W8Q-GHQ2
Vulnerability from github – Published: 2023-08-11 03:30 – Updated: 2024-04-04 06:50Race condition in firmware for some Intel(R) Ethernet Controllers and Adapters E810 Series before version 1.7.2.4 may allow an authenticated user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2023-22276"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-421"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-11T03:15:16Z",
"severity": "MODERATE"
},
"details": "Race condition in firmware for some Intel(R) Ethernet Controllers and Adapters E810 Series before version 1.7.2.4 may allow an authenticated user to potentially enable denial of service via local access.",
"id": "GHSA-4w59-2w8q-ghq2",
"modified": "2024-04-04T06:50:31Z",
"published": "2023-08-11T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22276"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230915-0007"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00835.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4W5G-R898-RJ85
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a race between renames and directory logging
We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed.
This is best explained following a step by step analysis of an interleaving of steps that lead into this situation.
Consider the initial conditions:
1) We are at transaction N;
2) We have directories A and B created in a past transaction (< N);
3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);
4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).
The steps leading to a file loss are the following and for all of them we are under transaction N:
1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir();
2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename();
3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref();
4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir();
5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same);
6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X;
7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1;
8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that.
Note that logging directory A doesn't fallback to a transaction
commit because its last_unlink_trans has a lower value than the
current transaction's id (see step 4);
9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;
10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened.
We have a log tree without any directory entry for inode Y, so the
log replay code deletes the entry for inode Y, name "A/bar", from the
subvolume tree since it doesn't exist in the log tree and the log
tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY
item that covers the index range for the dentry that corresponds to
"A/bar").
Since there's no other hard link for inode Y and the log replay code
deletes the name "A/bar", the file is lost.
The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y ("A/bar").
Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-38365"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix a race between renames and directory logging\n\nWe have a race between a rename and directory inode logging that if it\nhappens and we crash/power fail before the rename completes, the next time\nthe filesystem is mounted, the log replay code will end up deleting the\nfile that was being renamed.\n\nThis is best explained following a step by step analysis of an interleaving\nof steps that lead into this situation.\n\nConsider the initial conditions:\n\n1) We are at transaction N;\n\n2) We have directories A and B created in a past transaction (\u003c N);\n\n3) We have inode X corresponding to a file that has 2 hardlinks, one in\n directory A and the other in directory B, so we\u0027ll name them as\n \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a\n past transaction (\u003c N);\n\n4) We have inode Y corresponding to a file that as a single hard link and\n is located in directory A, we\u0027ll name it as \"A/bar\". This file was also\n persisted in a past transaction (\u003c N).\n\nThe steps leading to a file loss are the following and for all of them we\nare under transaction N:\n\n 1) Link \"A/foo_link1\" is removed, so inode\u0027s X last_unlink_trans field\n is updated to N, through btrfs_unlink() -\u003e btrfs_record_unlink_dir();\n\n 2) Task A starts a rename for inode Y, with the goal of renaming from\n \"A/bar\" to \"A/baz\", so we enter btrfs_rename();\n\n 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling\n btrfs_insert_inode_ref();\n\n 4) Because the rename happens in the same directory, we don\u0027t set the\n last_unlink_trans field of directoty A\u0027s inode to the current\n transaction id, that is, we don\u0027t cal btrfs_record_unlink_dir();\n\n 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY\n and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()\n (actually the dir index item is added as a delayed item, but the\n effect is the same);\n\n 6) Now before task A adds the new entry \"A/baz\" to directory A by\n calling btrfs_add_link(), another task, task B is logging inode X;\n\n 7) Task B starts a fsync of inode X and after logging inode X, at\n btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since\n inode X has a last_unlink_trans value of N, set at in step 1;\n\n 8) At btrfs_log_all_parents() we search for all parent directories of\n inode X using the commit root, so we find directories A and B and log\n them. Bu when logging direct A, we don\u0027t have a dir index item for\n inode Y anymore, neither the old name \"A/bar\" nor for the new name\n \"A/baz\" since the rename has deleted the old name but has not yet\n inserted the new name - task A hasn\u0027t called yet btrfs_add_link() to\n do that.\n\n Note that logging directory A doesn\u0027t fallback to a transaction\n commit because its last_unlink_trans has a lower value than the\n current transaction\u0027s id (see step 4);\n\n 9) Task B finishes logging directories A and B and gets back to\n btrfs_sync_file() where it calls btrfs_sync_log() to persist the log\n tree;\n\n10) Task B successfully persisted the log tree, btrfs_sync_log() completed\n with success, and a power failure happened.\n\n We have a log tree without any directory entry for inode Y, so the\n log replay code deletes the entry for inode Y, name \"A/bar\", from the\n subvolume tree since it doesn\u0027t exist in the log tree and the log\n tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY\n item that covers the index range for the dentry that corresponds to\n \"A/bar\").\n\n Since there\u0027s no other hard link for inode Y and the log replay code\n deletes the name \"A/bar\", the file is lost.\n\nThe issue wouldn\u0027t happen if task B synced the log only after task A\ncalled btrfs_log_new_name(), which would update the log with the new name\nfor inode Y (\"A/bar\").\n\nFix this by pinning the log root during renames before removing the old\ndirectory entry, and unpinning af\n---truncated---",
"id": "GHSA-4w5g-r898-rj85",
"modified": "2025-12-16T18:31:30Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38365"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-4WCM-FJH2-X4HG
Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows User Interface Core allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-32163"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T18:17:18Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows User Interface Core allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-4wcm-fjh2-x4hg",
"modified": "2026-04-14T18:30:41Z",
"published": "2026-04-14T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32163"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32163"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WP4-8C2W-49HV
Vulnerability from github – Published: 2026-02-10 06:30 – Updated: 2026-02-10 06:30A race condition vulnerability exists in the SAP Commerce cloud. Because of this when an attacker adds products to a cart, it may result in a cart entry being created with erroneous product value which could be checked out. This leads to high impact on data integrity, with no impact on data confidentiality or availability of the application.
{
"affected": [],
"aliases": [
"CVE-2026-23684"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-366"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T04:16:02Z",
"severity": "MODERATE"
},
"details": "A race condition vulnerability exists in the SAP Commerce cloud. Because of this when an attacker adds products to a cart, it may result in a cart entry being created with erroneous product value which could be checked out. This leads to high impact on data integrity, with no impact on data confidentiality or availability of the application.",
"id": "GHSA-4wp4-8c2w-49hv",
"modified": "2026-02-10T06:30:38Z",
"published": "2026-02-10T06:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23684"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3689543"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4WPH-PWC5-WP7G
Vulnerability from github – Published: 2022-12-13 21:30 – Updated: 2022-12-13 21:30Windows Error Reporting Elevation of Privilege Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-44669"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Error Reporting Elevation of Privilege Vulnerability.",
"id": "GHSA-4wph-pwc5-wp7g",
"modified": "2022-12-13T21:30:26Z",
"published": "2022-12-13T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44669"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-44669"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-44669"
}
],
"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-4WQW-J3VX-3HWJ
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06There is a multiple threads race condition vulnerability in Huawei product. A race condition exists for concurrent I/O read by multiple threads. An attacker with the root permission can exploit this vulnerability by performing some operations. Successful exploitation of this vulnerability may cause the system to crash. Affected product versions include: ManageOne 6.5.1.SPC200, 8.0.0,8.0.0-LCND81, 8.0.0.SPC100, 8.0.1,8.0.RC2, 8.0.RC3, 8.0.RC3.SPC100;SMC2.0 V600R019C10SPC700,V600R019C10SPC702, V600R019C10SPC703,V600R019C10SPC800, V600R019C10SPC900, V600R019C10SPC910, V600R019C10SPC920, V600R019C10SPC921, V600R019C10SPC922, V600R019C10SPC930, V600R019C10SPC931
{
"affected": [],
"aliases": [
"CVE-2021-22340"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T19:15:00Z",
"severity": "MODERATE"
},
"details": "There is a multiple threads race condition vulnerability in Huawei product. A race condition exists for concurrent I/O read by multiple threads. An attacker with the root permission can exploit this vulnerability by performing some operations. Successful exploitation of this vulnerability may cause the system to crash. Affected product versions include: ManageOne 6.5.1.SPC200, 8.0.0,8.0.0-LCND81, 8.0.0.SPC100, 8.0.1,8.0.RC2, 8.0.RC3, 8.0.RC3.SPC100;SMC2.0 V600R019C10SPC700,V600R019C10SPC702, V600R019C10SPC703,V600R019C10SPC800, V600R019C10SPC900, V600R019C10SPC910, V600R019C10SPC920, V600R019C10SPC921, V600R019C10SPC922, V600R019C10SPC930, V600R019C10SPC931",
"id": "GHSA-4wqw-j3vx-3hwj",
"modified": "2022-05-24T19:06:29Z",
"published": "2022-05-24T19:06:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22340"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210428-01-racecondition-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- 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
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
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
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
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
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
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.