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.
2900 vulnerabilities reference this CWE, most recent first.
GHSA-VG58-9G8J-FJ6X
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-11-11 15:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Hyper-V allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-54115"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T17:15:57Z",
"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-vg58-9g8j-fj6x",
"modified": "2025-11-11T15:31:19Z",
"published": "2025-09-09T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54115"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54115"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-54115-detection-script-privilege-elevation-vulnerability-in-windows-hyper-v"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-54115-mitigation-script-privilege-elevation-vulnerability-in-windows-hyper-v"
}
],
"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-VG9C-MRP6-2MH9
Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30In aee daemon, there is a possible system crash due to a race condition. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10190802; Issue ID: MSV-4833.
{
"affected": [],
"aliases": [
"CVE-2025-20765"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-02T03:16:17Z",
"severity": "MODERATE"
},
"details": "In aee daemon, there is a possible system crash due to a race condition. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10190802; Issue ID: MSV-4833.",
"id": "GHSA-vg9c-mrp6-2mh9",
"modified": "2025-12-02T15:30:30Z",
"published": "2025-12-02T03:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20765"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
}
],
"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-VG9G-89FH-G3HW
Vulnerability from github – Published: 2022-03-11 00:01 – Updated: 2022-03-18 00:01Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
{
"affected": [],
"aliases": [
"CVE-2022-23042"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-10T20:15:00Z",
"severity": "HIGH"
},
"details": "Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn\u0027t check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042",
"id": "GHSA-vg9g-89fh-g3hw",
"modified": "2022-03-18T00:01:19Z",
"published": "2022-03-11T00:01:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23042"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-396.txt"
}
],
"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-VGP8-265X-9XJ2
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Services Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49115"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:37Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Services Remote Code Execution Vulnerability",
"id": "GHSA-vgp8-265x-9xj2",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49115"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49115"
}
],
"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-VGV8-G935-V6MX
Vulnerability from github – Published: 2023-12-08 18:30 – Updated: 2023-12-13 18:31there is a possible use after free 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.
{
"affected": [],
"aliases": [
"CVE-2023-48420"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-08T16:15:18Z",
"severity": "MODERATE"
},
"details": "there is a possible use after free 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.\n\n",
"id": "GHSA-vgv8-g935-v6mx",
"modified": "2023-12-13T18:31:02Z",
"published": "2023-12-08T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48420"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-12-01"
}
],
"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-VH3W-X8QX-RVFM
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-02 00:31In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between login_work and the login thread
In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login).
The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0
Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsi_target_do_login()
{
"affected": [],
"aliases": [
"CVE-2022-50350"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()",
"id": "GHSA-vh3w-x8qx-rvfm",
"modified": "2025-12-02T00:31:10Z",
"published": "2025-09-16T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50350"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1533b8b3058db618409f41554ebe768c2e3acfae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ecdca49ca49d4770639d81503c873b6d25887c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fec1b2fa62c162d03f5dcd7b03e3c89d3116d49f"
}
],
"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-VH4P-6J7G-F4J9
Vulnerability from github – Published: 2021-08-25 20:49 – Updated: 2021-08-19 20:49An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "lock_api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-35911"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T20:49:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness.",
"id": "GHSA-vh4p-6j7g-f4j9",
"modified": "2021-08-19T20:49:28Z",
"published": "2021-08-25T20:49:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35911"
},
{
"type": "WEB",
"url": "https://github.com/Amanieu/parking_lot/pull/262"
},
{
"type": "PACKAGE",
"url": "https://github.com/Amanieu/parking_lot"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0070.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 lock_api"
}
GHSA-VH57-R7RP-9489
Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-24 00:00In TBD of TBD, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege in the kernel with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-219513976References: Upstream kernel
{
"affected": [],
"aliases": [
"CVE-2022-20148"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-15T14:15:00Z",
"severity": "MODERATE"
},
"details": "In TBD of TBD, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege in the kernel with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-219513976References: Upstream kernel",
"id": "GHSA-vh57-r7rp-9489",
"modified": "2022-06-24T00:00:24Z",
"published": "2022-06-16T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20148"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-06-01"
}
],
"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-VH5J-5FHQ-9XWG
Vulnerability from github – Published: 2025-06-27 22:06 – Updated: 2025-06-30 12:53Hi team,
I was looking at the recent fix and you limited the exploitability of race conditions but unfortunately it is still possible to exploit the issue since two requests happening at the exact same time will still go through. You should be able to completely fix the race conditions by leveraging SQLITE write lock and just send one query.
Summary
The /get-patch endpoint processes a purchase in two separate database queries: a SELECT that verifies the token is unused, followed by an UPDATE that marks the token as used. Because SQLite only guards each statement, a malicious actor can issue two requests at the exact same moment and have both SELECT statements succeed before either UPDATE runs.
Details
The handler executes (step 1):
SELECT id, token_used_at FROM purchases WHERE patch_id = ? AND purchase_token = ? AND status = 'COMPLETED'
If token_used_at IS NULL, the request passes the check (step 2):
if (row.token_used_at) {
return res.status(403).json({ error: "Purchase token has already been used." });
}
The handler finally runs (step 3):
UPDATE purchases SET token_used_at = CURRENT_TIMESTAMP WHERE id = ?
When two requests arrive at the same time, they both finish step 1 while the row is still unused. SQLite serializes writers only per statement, so each request believes it has exclusive access. Both decrypt and return the patch, and both UPDATE statements succeed.
PoC
To perform this attack, you need to send two requests at the exact same time.
Impact
An attacker who possesses a valid purchase token can replay it and receive multiple copies of the paid patch, or distribute one copy while still keeping their own. This results in revenue loss and undermines license enforcement.
Remediation
Replace the read-then-write sequence with a single atomic statement that both validates and consumes the token while SQLite holds the write lock:
const row = db.prepare(`
UPDATE purchases
SET token_used_at = CURRENT_TIMESTAMP
WHERE patch_id = ?
AND purchase_token = ?
AND status = 'COMPLETED'
AND token_used_at IS NULL
RETURNING id;
`).get(patchId, token);
if (!row) return res.status(403).json({ error: 'Invalid or already-used token.' });
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.1.2"
},
"package": {
"ecosystem": "npm",
"name": "taylored"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-27T22:06:48Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "Hi team,\n\nI was looking at the recent fix and you limited the exploitability of race conditions but unfortunately it is still possible to exploit the issue since two requests happening at the exact same time will still go through. You should be able to completely fix the race conditions by leveraging SQLITE write lock and just send one query.\n\n### Summary\nThe /get-patch endpoint processes a purchase in two separate database queries: a SELECT that verifies the token is unused, followed by an UPDATE that marks the token as used. Because SQLite only guards each statement, a malicious actor can issue two requests at the exact same moment and have both SELECT statements succeed before either UPDATE runs.\n\n### Details\n\nThe handler executes (step 1):\n\n```\nSELECT id, token_used_at FROM purchases WHERE patch_id = ? AND purchase_token = ? AND status = \u0027COMPLETED\u0027\n```\n\nIf token_used_at IS NULL, the request passes the check (step 2): \n```\n if (row.token_used_at) {\n return res.status(403).json({ error: \"Purchase token has already been used.\" });\n }\n```\n\n\nThe handler finally runs (step 3):\n\n```\nUPDATE purchases SET token_used_at = CURRENT_TIMESTAMP WHERE id = ?\n```\n\n\nWhen two requests arrive at the same time, they both finish step 1 while the row is still unused. SQLite serializes writers only per statement, so each request believes it has exclusive access. Both decrypt and return the patch, and both UPDATE statements succeed.\n\n### PoC\nTo perform this attack, you need to send two requests at the exact same time. \n\n### Impact\nAn attacker who possesses a valid purchase token can replay it and receive multiple copies of the paid patch, or distribute one copy while still keeping their own. This results in revenue loss and undermines license enforcement.\n\n\n### Remediation\n\nReplace the read-then-write sequence with a single atomic statement that both validates and consumes the token while SQLite holds the write lock:\n\n```\nconst row = db.prepare(`\n UPDATE purchases\n SET token_used_at = CURRENT_TIMESTAMP\n WHERE patch_id = ?\n AND purchase_token = ?\n AND status = \u0027COMPLETED\u0027\n AND token_used_at IS NULL\n RETURNING id;\n`).get(patchId, token);\n\nif (!row) return res.status(403).json({ error: \u0027Invalid or already-used token.\u0027 });\n```",
"id": "GHSA-vh5j-5fhq-9xwg",
"modified": "2025-06-30T12:53:28Z",
"published": "2025-06-27T22:06:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tailot/taylored/security/advisories/GHSA-vh5j-5fhq-9xwg"
},
{
"type": "WEB",
"url": "https://github.com/tailot/taylored/commit/fdf67a6fba0deae30912905a79fb5a9e83751a79"
},
{
"type": "PACKAGE",
"url": "https://github.com/tailot/taylored"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Taylor has race condition in /get-patch that allows purchase token replay"
}
GHSA-VH63-H6GP-HW6W
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02An issue was discovered in Prosody before 0.11.9. It does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker.
{
"affected": [],
"aliases": [
"CVE-2021-32921"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-13T16:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Prosody before 0.11.9. It does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker.",
"id": "GHSA-vh63-h6gp-hw6w",
"modified": "2022-05-24T19:02:20Z",
"published": "2022-05-24T19:02:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32921"
},
{
"type": "WEB",
"url": "https://blog.prosody.im/prosody-0.11.9-released"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00016.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00018.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6MFFBZWXKPZEVZNQSVJNCUE7WRF3T7DG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GUN63AHEWB2WRROJHU3BVJRWLONCT2B7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LWJ2DG2DFJOEFEWOUN26IMYYWGSA2ZEE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202105-15"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4916"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/13/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/14/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.