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.
2895 vulnerabilities reference this CWE, most recent first.
GHSA-299W-8X68-PX6H
Vulnerability from github – Published: 2025-05-13 21:30 – Updated: 2025-05-13 21:30Race condition for some Intel(R) PROSet/Wireless WiFi Software for Windows before version 23.100 may allow an unauthenticated user to potentially enable denial of service via adjacent access.
{
"affected": [],
"aliases": [
"CVE-2025-20039"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-13T21:16:04Z",
"severity": "MODERATE"
},
"details": "Race condition for some Intel(R) PROSet/Wireless WiFi Software for Windows before version 23.100 may allow an unauthenticated user to potentially enable denial of service via adjacent access.",
"id": "GHSA-299w-8x68-px6h",
"modified": "2025-05-13T21:30:55Z",
"published": "2025-05-13T21:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20039"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01270.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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-29V7-3V4C-GF38
Vulnerability from github – Published: 2021-08-25 20:57 – Updated: 2023-06-13 20:11In the affected versions of this crate, LockWeak unconditionally implemented Send with no trait bounds on T. LockWeak doesn't own T and only provides &T. This allows concurrent access to a non-Sync T, which can cause undefined behavior like data races.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "parc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36454"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-18T20:23:35Z",
"nvd_published_at": "2021-08-08T06:15:00Z",
"severity": "HIGH"
},
"details": "In the affected versions of this crate, LockWeak\u003cT\u003e unconditionally implemented Send with no trait bounds on T. LockWeak\u003cT\u003e doesn\u0027t own T and only provides \u0026T. This allows concurrent access to a non-Sync T, which can cause undefined behavior like data races.",
"id": "GHSA-29v7-3v4c-gf38",
"modified": "2023-06-13T20:11:11Z",
"published": "2021-08-25T20:57:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36454"
},
{
"type": "WEB",
"url": "https://github.com/hyyking/rustracts/pull/6"
},
{
"type": "PACKAGE",
"url": "https://github.com/hyyking/rustracts/tree/master/parc"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/parc/RUSTSEC-2020-0134.md"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0134.html"
}
],
"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": "Data races in parc"
}
GHSA-29WH-8W97-366V
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-25 18:30In the Linux kernel, the following vulnerability has been resolved:
fscache: Fix oops due to race with cookie_lru and use_cookie
If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it.
When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL.
Fix the oops by clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs.
BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100
{
"affected": [],
"aliases": [
"CVE-2022-48989"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Fix oops due to race with cookie_lru and use_cookie\n\nIf a cookie expires from the LRU and the LRU_DISCARD flag is set, but\nthe state machine has not run yet, it\u0027s possible another thread can call\nfscache_use_cookie and begin to use it.\n\nWhen the cookie_worker finally runs, it will see the LRU_DISCARD flag\nset, transition the cookie-\u003estate to LRU_DISCARDING, which will then\nwithdraw the cookie. Once the cookie is withdrawn the object is removed\nthe below oops will occur because the object associated with the cookie\nis now NULL.\n\nFix the oops by clearing the LRU_DISCARD bit if another thread uses the\ncookie before the cookie_worker runs.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n ...\n CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022\n Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs]\n RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles]\n ...\n Call Trace:\n netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs]\n process_one_work+0x217/0x3e0\n worker_thread+0x4a/0x3b0\n kthread+0xd6/0x100",
"id": "GHSA-29wh-8w97-366v",
"modified": "2024-10-25T18:30:48Z",
"published": "2024-10-21T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48989"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37f0b459c9b67e14fe4dcc3a15d286c4436ed01d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5b52de3214a29911f949459a79f6640969b5487"
}
],
"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-29XP-372Q-XQPH
Vulnerability from github – Published: 2025-10-30 17:13 – Updated: 2025-10-30 19:53Summary
Using .t (aka .list) with { sync: true } to read tar entry contents returns uninitialized memory contents if tar file was changed on disk to a smaller size while being read.
Details
See: * https://github.com/isaacs/node-tar/issues/445 * https://github.com/isaacs/node-tar/pull/446 * Regression happened in https://github.com/isaacs/node-tar/commit/5330eb04bc43014f216e5c271b40d5c00d45224d
PoC
A:
import * as tar from 'tar'
import fs from 'node:fs'
fs.writeFileSync('tar.test.tmp', Buffer.alloc(1*1024))
// from readme
const filesAdded = []
tar.c(
{
sync: true,
file: 'tar.test.tmp.tar',
onWriteEntry(entry) {
// initially, it's uppercase and 0o644
console.log('adding', entry.path, entry.stat.mode.toString(8))
// make all the paths lowercase
entry.path = entry.path.toLowerCase()
// make the entry executable
entry.stat.mode = 0o755
// in the archive, it's lowercase and 0o755
filesAdded.push([entry.path, entry.stat.mode.toString(8)])
},
},
['./tar.test.tmp'],
)
const a = fs.readFileSync('tar.test.tmp.tar')
for (let i = 0; ; i++){
if (i % 10000 === 0) console.log(i)
fs.writeFileSync('tar.test.tmp.tar', a)
fs.truncateSync('tar.test.tmp.tar', 600)
}
B (vulnerable):
import * as tar from 'tar'
import * as fs from 'fs'
while (true) {
fs.readFileSync(import.meta.filename)
tar.t({
sync: true,
file: 'tar.test.tmp.tar',
onReadEntry: e => e.on('data', b => {
const a = b.filter(x => x)
if (a.length > 0) console.log(a.toString())
})
})
}
Run A and B in parallel on Node.js 22 or >=25.1.0
Dumps B memory (wait for some time to observe text data)
Impact
Exposes process memory and could result in e.g. unintentionally (aka attacker-controlled) attempting to process sensitive data rather than tar entry contents. Uninitialized memory can contain unrelated file contents, environment variables, passwords, etc.
To execute, an attacker must reduce the file size to boundary between a tar header and body block, in the time between when the tar archive file size is read via stat, and the time when the tar archive parser reaches the entry that is truncated. If the file is truncated at a different boundary, then the uninitialized data will very likely not be a valid tar entry, causing the parser to treat the entry as a damaged archive (that is, throwing an error in strict: true mode, or by default, skipping the entry harmlessly).
This is conditional on using the sync: true option to the tar.list/tar.t method, and the 7.5.1 version specifically. Earlier versions were not affected.
This is also conditional to attacker being able to truncate (or induce a truncation/replacement) of a file on disk (e.g. in cache).
If the tar file is initially larger than the opt.maxReadSize (16kb by default), then uninitialized memory is not exposed to user code, and instead the program enters an infinite loop, causing a DoS rather than an information disclosure vulnerability.
By default, tar.list does not process tar archive entry body content. So, this is further conditional on the user code doing something with the tar entry file contents in an onReadEntry method which would expose the file contents (for example, attempting to parse them in such a way that the uninitialized data could appear in an error message).
Other methods in this library (tar.extract, etc.) are not affected by this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "tar"
},
"ranges": [
{
"events": [
{
"introduced": "7.5.1"
},
{
"fixed": "7.5.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"7.5.1"
]
}
],
"aliases": [
"CVE-2025-64118"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-30T17:13:17Z",
"nvd_published_at": "2025-10-30T18:15:33Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nUsing `.t` (aka `.list`) with `{ sync: true }` to read tar entry contents returns uninitialized memory contents if tar file was changed on disk to a smaller size while being read.\n\n### Details\n\nSee:\n* https://github.com/isaacs/node-tar/issues/445\n* https://github.com/isaacs/node-tar/pull/446\n* Regression happened in https://github.com/isaacs/node-tar/commit/5330eb04bc43014f216e5c271b40d5c00d45224d\n\n### PoC\n\nA:\n```js\nimport * as tar from \u0027tar\u0027\nimport fs from \u0027node:fs\u0027\n\nfs.writeFileSync(\u0027tar.test.tmp\u0027, Buffer.alloc(1*1024))\n\n// from readme\nconst filesAdded = []\ntar.c(\n {\n sync: true,\n file: \u0027tar.test.tmp.tar\u0027,\n onWriteEntry(entry) {\n // initially, it\u0027s uppercase and 0o644\n console.log(\u0027adding\u0027, entry.path, entry.stat.mode.toString(8))\n // make all the paths lowercase\n entry.path = entry.path.toLowerCase()\n // make the entry executable\n entry.stat.mode = 0o755\n // in the archive, it\u0027s lowercase and 0o755\n filesAdded.push([entry.path, entry.stat.mode.toString(8)])\n },\n },\n [\u0027./tar.test.tmp\u0027],\n)\n\nconst a = fs.readFileSync(\u0027tar.test.tmp.tar\u0027)\n\nfor (let i = 0; ; i++){\n if (i % 10000 === 0) console.log(i)\n fs.writeFileSync(\u0027tar.test.tmp.tar\u0027, a)\n fs.truncateSync(\u0027tar.test.tmp.tar\u0027, 600)\n}\n```\n\nB (vulnerable):\n```js\nimport * as tar from \u0027tar\u0027\nimport * as fs from \u0027fs\u0027\n\nwhile (true) {\n fs.readFileSync(import.meta.filename)\n tar.t({\n sync: true,\n file: \u0027tar.test.tmp.tar\u0027,\n onReadEntry: e =\u003e e.on(\u0027data\u0027, b =\u003e {\n const a = b.filter(x =\u003e x)\n if (a.length \u003e 0) console.log(a.toString())\n })\n })\n}\n```\n\nRun A and B in parallel on Node.js 22 or \u003e=25.1.0\n\nDumps `B` memory (wait for some time to observe text data)\n\n### Impact\n\nExposes process memory and could result in e.g. unintentionally (aka attacker-controlled) attempting to process sensitive data rather than tar entry contents. Uninitialized memory can contain unrelated file contents, environment variables, passwords, etc.\n\nTo execute, an attacker must reduce the file size to boundary between a tar header and body block, in the time between when the tar archive file size is read via `stat`, and the time when the tar archive parser reaches the entry that is truncated. If the file is truncated at a different boundary, then the uninitialized data will very likely not be a valid tar entry, causing the parser to treat the entry as a damaged archive (that is, throwing an error in `strict: true` mode, or by default, skipping the entry harmlessly).\n\nThis is conditional on using the `sync: true` option to the `tar.list`/`tar.t` method, and the `7.5.1` version specifically. Earlier versions were not affected.\n\nThis is also conditional to attacker being able to truncate (or induce a truncation/replacement) of a file on disk (e.g. in cache).\n\nIf the tar file is initially larger than the `opt.maxReadSize` (16kb by default), then uninitialized memory is not exposed to user code, and instead the program enters an infinite loop, causing a DoS rather than an information disclosure vulnerability.\n\nBy default, `tar.list` does _not_ process tar archive entry body content. So, this is further conditional on the user code doing something with the tar entry file contents in an `onReadEntry` method which would expose the file contents (for example, attempting to parse them in such a way that the uninitialized data could appear in an error message).\n\nOther methods in this library (`tar.extract`, etc.) are not affected by this vulnerability.",
"id": "GHSA-29xp-372q-xqph",
"modified": "2025-10-30T19:53:34Z",
"published": "2025-10-30T17:13:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/security/advisories/GHSA-29xp-372q-xqph"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64118"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/issues/445"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/pull/446"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/commit/5330eb04bc43014f216e5c271b40d5c00d45224d"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/commit/5e1a8e638600d3c3a2969b4de6a6ec44fa8d74c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/isaacs/node-tar"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:H/VI:L/VA:L/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "node-tar has a race condition leading to uninitialized memory exposure"
}
GHSA-2CJM-2GWV-M892
Vulnerability from github – Published: 2026-03-12 17:29 – Updated: 2026-03-13 13:36Impact
Parse Server's built-in OAuth2 auth adapter exports a singleton instance that is reused directly across all OAuth2 provider configurations. Under concurrent authentication requests for different OAuth2 providers, one provider's token validation may execute using another provider's configuration, potentially allowing a token that should be rejected by one provider to be accepted because it is validated against a different provider's policy.
Deployments that configure multiple OAuth2 providers via the oauth2: true flag are affected.
Patches
The fix ensures that a new adapter instance is created for each provider instead of reusing the singleton, so each provider's configuration is isolated.
Workarounds
There is no known workaround. If only a single OAuth2 provider is configured, the race condition cannot occur.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-2cjm-2gwv-m892
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.11
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.37
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.6.0-alpha.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.37"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32242"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T17:29:49Z",
"nvd_published_at": "2026-03-12T19:16:19Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nParse Server\u0027s built-in OAuth2 auth adapter exports a singleton instance that is reused directly across all OAuth2 provider configurations. Under concurrent authentication requests for different OAuth2 providers, one provider\u0027s token validation may execute using another provider\u0027s configuration, potentially allowing a token that should be rejected by one provider to be accepted because it is validated against a different provider\u0027s policy.\n\nDeployments that configure multiple OAuth2 providers via the `oauth2: true` flag are affected.\n\n### Patches\n\nThe fix ensures that a new adapter instance is created for each provider instead of reusing the singleton, so each provider\u0027s configuration is isolated.\n\n### Workarounds\n\nThere is no known workaround. If only a single OAuth2 provider is configured, the race condition cannot occur.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-2cjm-2gwv-m892\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.11\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.37",
"id": "GHSA-2cjm-2gwv-m892",
"modified": "2026-03-13T13:36:09Z",
"published": "2026-03-12T17:29:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-2cjm-2gwv-m892"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32242"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/8.6.37"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server\u0027s OAuth2 adapter shares mutable state across providers via singleton instance"
}
GHSA-2F8J-M7PX-V4P9
Vulnerability from github – Published: 2022-05-14 03:24 – Updated: 2022-05-14 03:24In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel before security patch level 2018-04-05, due to a race condition, a Use After Free condition can occur in the WLAN driver.
{
"affected": [],
"aliases": [
"CVE-2018-5826"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-03T17:29:00Z",
"severity": "MODERATE"
},
"details": "In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel before security patch level 2018-04-05, due to a race condition, a Use After Free condition can occur in the WLAN driver.",
"id": "GHSA-2f8j-m7px-v4p9",
"modified": "2022-05-14T03:24:11Z",
"published": "2022-05-14T03:24:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5826"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2018-04-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2FF2-J84C-3HW4
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39Race condition in HAL layer while processing callback objects received from HIDL due to lack of synchronization between accessing objects in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2020-11152"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-21T10:15:00Z",
"severity": "MODERATE"
},
"details": "Race condition in HAL layer while processing callback objects received from HIDL due to lack of synchronization between accessing objects in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
"id": "GHSA-2ff2-j84c-3hw4",
"modified": "2022-05-24T17:39:59Z",
"published": "2022-05-24T17:39:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11152"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/december-2020-bulletin"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/december-2020-security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2FH4-CPV8-68HG
Vulnerability from github – Published: 2022-05-17 05:24 – Updated: 2024-03-21 03:33** DISPUTED ** Race condition in Online Solutions Security Suite 1.5.14905.0 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute.
{
"affected": [],
"aliases": [
"CVE-2010-5170"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-08-25T21:55:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** Race condition in Online Solutions Security Suite 1.5.14905.0 on Windows XP allows local users to bypass kernel-mode hook handlers, and execute dangerous code that would otherwise be blocked by a handler but not blocked by signature-based malware detection, via certain user-space memory changes during hook-handler execution, aka an argument-switch attack or a KHOBE attack. NOTE: this issue is disputed by some third parties because it is a flaw in a protection mechanism for situations where a crafted program has already begun to execute.",
"id": "GHSA-2fh4-cpv8-68hg",
"modified": "2024-03-21T03:33:10Z",
"published": "2022-05-17T05:24:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-5170"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/bugtraq/2010-05/0026.html"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/fulldisclosure/2010-05/0066.html"
},
{
"type": "WEB",
"url": "http://countermeasures.trendmicro.eu/you-just-cant-trust-a-drunk"
},
{
"type": "WEB",
"url": "http://matousec.com/info/advisories/khobe-8.0-earthquake-for-windows-desktop-security-software.php"
},
{
"type": "WEB",
"url": "http://matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php"
},
{
"type": "WEB",
"url": "http://www.f-secure.com/weblog/archives/00001949.html"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/67660"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/39924"
},
{
"type": "WEB",
"url": "http://www.theregister.co.uk/2010/05/07/argument_switch_av_bypass"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2FW9-CXCH-QX5H
Vulnerability from github – Published: 2026-04-09 00:32 – Updated: 2026-04-16 18:31Race in WebCodecs in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-5890"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T22:16:28Z",
"severity": "MODERATE"
},
"details": "Race in WebCodecs in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-2fw9-cxch-qx5h",
"modified": "2026-04-16T18:31:21Z",
"published": "2026-04-09T00:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5890"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/487259772"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2FXM-8374-C95M
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----
{
"affected": [],
"aliases": [
"CVE-2024-26960"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----",
"id": "GHSA-2fxm-8374-c95m",
"modified": "2026-05-12T12:31:43Z",
"published": "2024-05-01T06:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"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.