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.
2909 vulnerabilities reference this CWE, most recent first.
GHSA-PC3X-W29G-959C
Vulnerability from github – Published: 2022-05-14 01:48 – Updated: 2022-05-14 01:48In the ClearKey CAS descrambler, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android. Versions: Android-8.0 Android-8.1 Android-9. Android ID: A-113027383
{
"affected": [],
"aliases": [
"CVE-2018-9539"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-14T18:29:00Z",
"severity": "HIGH"
},
"details": "In the ClearKey CAS descrambler, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android. Versions: Android-8.0 Android-8.1 Android-9. Android ID: A-113027383",
"id": "GHSA-pc3x-w29g-959c",
"modified": "2022-05-14T01:48:13Z",
"published": "2022-05-14T01:48:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9539"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-11-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105865"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PCF4-GG6Q-6C32
Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2025-07-08 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Input Method Editor (IME) allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2025-47972"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-08T17:15:37Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Microsoft Input Method Editor (IME) allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-pcf4-gg6q-6c32",
"modified": "2025-07-08T18:31:44Z",
"published": "2025-07-08T18:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47972"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47972"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PF36-M74W-73JX
Vulnerability from github – Published: 2025-12-08 09:30 – Updated: 2025-12-08 09:30Multi-thread race condition vulnerability in the camera framework module. Impact: Successful exploitation of this vulnerability may affect availability.
{
"affected": [],
"aliases": [
"CVE-2025-66320"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T08:15:52Z",
"severity": "MODERATE"
},
"details": "Multi-thread race condition vulnerability in the camera framework module. Impact: Successful exploitation of this vulnerability may affect availability.",
"id": "GHSA-pf36-m74w-73jx",
"modified": "2025-12-08T09:30:18Z",
"published": "2025-12-08T09:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66320"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PF4Q-2JH7-79H5
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:57A race condition in specific microprocessors using Intel (R) DDIO cache allocation and RDMA may allow an authenticated user to potentially enable partial information disclosure via adjacent access.
{
"affected": [],
"aliases": [
"CVE-2019-11184"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-16T16:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition in specific microprocessors using Intel (R) DDIO cache allocation and RDMA may allow an authenticated user to potentially enable partial information disclosure via adjacent access.",
"id": "GHSA-pf4q-2jh7-79h5",
"modified": "2024-04-04T01:57:27Z",
"published": "2022-05-24T16:56:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11184"
},
{
"type": "WEB",
"url": "https://arxiv.org/abs/1909.04841"
},
{
"type": "WEB",
"url": "https://ieeexplore.ieee.org/document/9152768"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190926-0001"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K43220413"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K43220413?utm_source=f5support\u0026amp%3Butm_medium=RSS"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K43220413?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00290.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PFJQ-935C-4895
Vulnerability from github – Published: 2021-08-25 21:00 – Updated: 2023-06-13 22:27Affected versions of this crate unconditionally implement Sync for SyncRef<T>. This definition allows data races if &T is accessible through &SyncRef.
SyncRef<T> derives Clone and Debug, and the default implementations of those traits access &T by invoking T::clone() & T::fmt(). It is possible to create data races & undefined behavior by concurrently invoking SyncRef<T>::clone() or SyncRef<T>::fmt() from multiple threads with T: !Sync.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "v9"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.43"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-05T21:37:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Affected versions of this crate unconditionally implement `Sync` for `SyncRef\u003cT\u003e`. This definition allows data races if `\u0026T` is accessible through `\u0026SyncRef`.\n\n`SyncRef\u003cT\u003e` derives `Clone` and `Debug`, and the default implementations of those traits access `\u0026T` by invoking `T::clone()` \u0026 `T::fmt()`. It is possible to create data races \u0026 undefined behavior by concurrently invoking `SyncRef\u003cT\u003e::clone()` or `SyncRef\u003cT\u003e::fmt()` from multiple threads with `T: !Sync`.\n",
"id": "GHSA-pfjq-935c-4895",
"modified": "2023-06-13T22:27:40Z",
"published": "2021-08-25T21:00:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/purpleposeidon/v9/issues/1"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0127.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 v9"
}
GHSA-PFM7-36QC-84V9
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-18 15:30In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_rndis: Protect RNDIS options with mutex
The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs.
Use existing mutex to protect these options. This issue was identified during code inspection.
{
"affected": [],
"aliases": [
"CVE-2026-43342"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_rndis: Protect RNDIS options with mutex\n\nThe class/subclass/protocol options are suspectible to race conditions\nas they can be accessed concurrently through configfs.\n\nUse existing mutex to protect these options. This issue was identified\nduring code inspection.",
"id": "GHSA-pfm7-36qc-84v9",
"modified": "2026-05-18T15:30:32Z",
"published": "2026-05-08T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43342"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a75d97c53477a59c0aa1c65f69038c719f9c5b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/209decd3f7901df9842b83f2540dc8685e344a07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/446f1842cda929c40d4697722bfdcfb334bc9692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65b7dbf80a1627667c241fff7c1c224f3118014f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d8fa3b8783ab95a46e20d97fbeeede719b2efda"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d8c68b1fc06ece60cf43e1306ff0f4ac121547e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1b3d5b0acb194efe20fc5864ee03439fa7bd45c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb5316b37288ab8791584e32f114c4f41ad45b67"
}
],
"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-PFQR-532X-CJJM
Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-21 18:32Use after free in Tab Strip in Google Chrome on Chrome OS, Lacros prior to 105.0.5195.52 allowed a remote attacker who convinced a user to engage in specific UI interactions to potentially exploit heap corruption via crafted UI interaction.
{
"affected": [],
"aliases": [
"CVE-2022-3071"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-26T16:15:00Z",
"severity": "HIGH"
},
"details": "Use after free in Tab Strip in Google Chrome on Chrome OS, Lacros prior to 105.0.5195.52 allowed a remote attacker who convinced a user to engage in specific UI interactions to potentially exploit heap corruption via crafted UI interaction.",
"id": "GHSA-pfqr-532x-cjjm",
"modified": "2025-05-21T18:32:59Z",
"published": "2022-09-27T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3071"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop_30.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1333995"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202209-23"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PG45-3X6F-6R9M
Vulnerability from github – Published: 2022-05-14 03:27 – Updated: 2022-05-14 03:27An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. macOS before 10.12.5 is affected. The issue involves the "Security" component. A race condition allows attackers to bypass intended entitlement restrictions for sending XPC messages via a crafted app.
{
"affected": [],
"aliases": [
"CVE-2017-7004"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-03T06:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. macOS before 10.12.5 is affected. The issue involves the \"Security\" component. A race condition allows attackers to bypass intended entitlement restrictions for sending XPC messages via a crafted app.",
"id": "GHSA-pg45-3x6f-6r9m",
"modified": "2022-05-14T03:27:10Z",
"published": "2022-05-14T03:27:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7004"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207797"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207798"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/42145"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PG7C-462J-GRXV
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-26 22:48Mattermost versions 11.6.x <= 11.6.0, 11.5.x <= 11.5.3, 11.4.x <= 11.4.4, 10.11.x <= 10.11.14 fail to archive the channel before removing persistent notifications which allows authenticated user to crash the server via timing the creation of persistent notification message between the server deleting existing persistent notifications and archiving the channel. Mattermost Advisory ID: MMSA-2026-00637.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.6.0"
},
{
"fixed": "11.6.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"11.6.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.5.0"
},
{
"fixed": "11.5.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.4.0"
},
{
"fixed": "11.4.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-4635"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:48:42Z",
"nvd_published_at": "2026-05-22T11:16:22Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.6.x \u003c= 11.6.0, 11.5.x \u003c= 11.5.3, 11.4.x \u003c= 11.4.4, 10.11.x \u003c= 10.11.14 fail to archive the channel before removing persistent notifications which allows authenticated user to crash the server via timing the creation of persistent notification message between the server deleting existing persistent notifications and archiving the channel. Mattermost Advisory ID: MMSA-2026-00637.",
"id": "GHSA-pg7c-462j-grxv",
"modified": "2026-06-26T22:48:42Z",
"published": "2026-05-26T13:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4635"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mattermost doesn\u0027t archive the channel before removing persistent notifications"
}
GHSA-PGC5-4958-PW57
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()
Normally do_lock_mount(path, _) is locking a mountpoint pinned by *path and at the time when matching unlock_mount() unlocks that location it is still pinned by the same thing.
Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mnt_parent may change under us and none of the locks are held at that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided that m is mounted. * if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mnt_parent.
namespace_sem nests inside inode_lock(), so do_lock_mount() has to take inode_lock() before grabbing namespace_sem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode.
However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty.
What we need to do is grab both dentry and mount at the same time; that makes inode_lock() safe and avoids the problem with fs getting shut down under us. After taking namespace_sem we verify that path->mnt is still mounted (which stabilizes its ->mnt_parent) and check that it's still mounted at the same place. From that point on to the matching namespace_unlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs.
That solves the problem on do_lock_mount() side; unlock_mount() also has one, since dentry is guaranteed to stay pinned only until the namespace_unlock(). That's easy to fix - just have inode_unlock() done earlier, while it's still pinned by mp->m_dentry.
{
"affected": [],
"aliases": [
"CVE-2025-37988"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T18:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()\n\nNormally do_lock_mount(path, _) is locking a mountpoint pinned by\n*path and at the time when matching unlock_mount() unlocks that\nlocation it is still pinned by the same thing.\n\nUnfortunately, for \u0027beneath\u0027 case it\u0027s no longer that simple -\nthe object being locked is not the one *path points to. It\u0027s the\nmountpoint of path-\u003emnt. The thing is, without sufficient locking\n-\u003emnt_parent may change under us and none of the locks are held\nat that point. The rules are\n\t* mount_lock stabilizes m-\u003emnt_parent for any mount m.\n\t* namespace_sem stabilizes m-\u003emnt_parent, provided that\nm is mounted.\n\t* if either of the above holds and refcount of m is positive,\nwe are guaranteed the same for refcount of m-\u003emnt_parent.\n\nnamespace_sem nests inside inode_lock(), so do_lock_mount() has\nto take inode_lock() before grabbing namespace_sem. It does\nrecheck that path-\u003emnt is still mounted in the same place after\ngetting namespace_sem, and it does take care to pin the dentry.\nIt is needed, since otherwise we might end up with racing mount --move\n(or umount) happening while we were getting locks; in that case\ndentry would no longer be a mountpoint and could\u0027ve been evicted\non memory pressure along with its inode - not something you want\nwhen grabbing lock on that inode.\n\nHowever, pinning a dentry is not enough - the matching mount is\nalso pinned only by the fact that path-\u003emnt is mounted on top it\nand at that point we are not holding any locks whatsoever, so\nthe same kind of races could end up with all references to\nthat mount gone just as we are about to enter inode_lock().\nIf that happens, we are left with filesystem being shut down while\nwe are holding a dentry reference on it; results are not pretty.\n\nWhat we need to do is grab both dentry and mount at the same time;\nthat makes inode_lock() safe *and* avoids the problem with fs getting\nshut down under us. After taking namespace_sem we verify that\npath-\u003emnt is still mounted (which stabilizes its -\u003emnt_parent) and\ncheck that it\u0027s still mounted at the same place. From that point\non to the matching namespace_unlock() we are guaranteed that\nmount/dentry pair we\u0027d grabbed are also pinned by being the mountpoint\nof path-\u003emnt, so we can quietly drop both the dentry reference (as\nthe current code does) and mnt one - it\u0027s OK to do under namespace_sem,\nsince we are not dropping the final refs.\n\nThat solves the problem on do_lock_mount() side; unlock_mount()\nalso has one, since dentry is guaranteed to stay pinned only until\nthe namespace_unlock(). That\u0027s easy to fix - just have inode_unlock()\ndone earlier, while it\u0027s still pinned by mp-\u003em_dentry.",
"id": "GHSA-pgc5-4958-pw57",
"modified": "2025-11-14T18:31:20Z",
"published": "2025-05-20T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37988"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f435c1f4c48ff84968e2d9159f6fa41f46cf998"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a61afd54826ac24c2c93845c4f441dbc344875b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4b21e8cd3d7efa2deb9cff534f0133e84f35086"
}
],
"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"
}
]
}
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.