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.
2922 vulnerabilities reference this CWE, most recent first.
GHSA-FG7R-2G4J-5CGR
Vulnerability from github – Published: 2022-01-06 22:04 – Updated: 2023-06-13 22:01If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.
When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.
Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.14"
},
{
"fixed": "1.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.0"
},
{
"fixed": "1.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-45710"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-05T22:43:36Z",
"nvd_published_at": "2021-12-27T00:15:00Z",
"severity": "HIGH"
},
"details": "If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.\n\nWhen these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.\n\nNote that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.\n\n",
"id": "GHSA-fg7r-2g4j-5cgr",
"modified": "2023-06-13T22:01:00Z",
"published": "2022-01-06T22:04:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45710"
},
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/issues/4225"
},
{
"type": "PACKAGE",
"url": "https://github.com/tokio-rs/tokio"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/tokio/RUSTSEC-2021-0124.md"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0124.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": "Race Condition in tokio"
}
GHSA-FGC7-4PJ8-F29X
Vulnerability from github – Published: 2022-05-02 03:13 – Updated: 2022-05-02 03:13Race condition in AFP Server in Apple Mac OS X 10.5.6 allows local users to cause a denial of service (infinite loop) via unspecified vectors related to "file enumeration logic."
{
"affected": [],
"aliases": [
"CVE-2009-0142"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-02-12T23:30:00Z",
"severity": "LOW"
},
"details": "Race condition in AFP Server in Apple Mac OS X 10.5.6 allows local users to cause a denial of service (infinite loop) via unspecified vectors related to \"file enumeration logic.\"",
"id": "GHSA-fgc7-4pj8-f29x",
"modified": "2022-05-02T03:13:06Z",
"published": "2022-05-02T03:13:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0142"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2009/Feb/msg00000.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/33937"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT3438"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/33759"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/33812"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/0422"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FGCW-C69X-X32Q
Vulnerability from github – Published: 2026-07-19 06:30 – Updated: 2026-07-19 06:30A vulnerability was determined in allegro up to bcf65b994ef29fb3fc2e10b660e6288723d5209e. This impacts the function AssetLastHostname.increment_hostname of the file src/ralph/assets/models/assets.py of the component Hostname Allocation Handler. Executing a manipulation of the argument counter can lead to race condition. Attacks of this nature are highly complex. The exploitability is said to be difficult. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-16211"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T04:17:05Z",
"severity": "LOW"
},
"details": "A vulnerability was determined in allegro up to bcf65b994ef29fb3fc2e10b660e6288723d5209e. This impacts the function AssetLastHostname.increment_hostname of the file src/ralph/assets/models/assets.py of the component Hostname Allocation Handler. Executing a manipulation of the argument counter can lead to race condition. Attacks of this nature are highly complex. The exploitability is said to be difficult. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-fgcw-c69x-x32q",
"modified": "2026-07-19T06:30:24Z",
"published": "2026-07-19T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16211"
},
{
"type": "WEB",
"url": "https://github.com/allegro/ralph/issues/3950"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-16211"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/857935"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/380027"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/380027/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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-FGGM-CJ33-4GMM
Vulnerability from github – Published: 2022-05-17 05:24 – Updated: 2024-03-21 03:33** DISPUTED ** Race condition in Trend Micro Internet Security Pro 2010 17.50.1647.0000 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-5179"
],
"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 Trend Micro Internet Security Pro 2010 17.50.1647.0000 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-fggm-cj33-4gmm",
"modified": "2024-03-21T03:33:10Z",
"published": "2022-05-17T05:24:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-5179"
},
{
"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-FGWH-54WV-865R
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-06-06 21:30An issue was discovered in drivers/media/platform/vivid in the Linux kernel through 5.3.8. It is exploitable for privilege escalation on some Linux distributions where local users have /dev/video0 access, but only if the driver happens to be loaded. There are multiple race conditions during streaming stopping in this driver (part of the V4L2 subsystem). These issues are caused by wrong mutex locking in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out(), sdr_cap_stop_streaming(), and the corresponding kthreads. At least one of these race conditions leads to a use-after-free.
{
"affected": [],
"aliases": [
"CVE-2019-18683"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-04T16:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in drivers/media/platform/vivid in the Linux kernel through 5.3.8. It is exploitable for privilege escalation on some Linux distributions where local users have /dev/video0 access, but only if the driver happens to be loaded. There are multiple race conditions during streaming stopping in this driver (part of the V4L2 subsystem). These issues are caused by wrong mutex locking in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out(), sdr_cap_stop_streaming(), and the corresponding kthreads. At least one of these race conditions leads to a use-after-free.",
"id": "GHSA-fgwh-54wv-865r",
"modified": "2024-06-06T21:30:35Z",
"published": "2022-05-24T17:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18683"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/20191103221719.27118-1-alex.popov%40linux.com"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/20191103221719.27118-1-alex.popov@linux.com"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/10"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4254-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4254-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4258-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4284-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4287-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4287-2"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2019/11/02/1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00029.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/155890/Slackware-Security-Advisory-Slackware-14.2-kernel-Updates.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/11/05/1"
}
],
"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-FH24-7CC2-VRH4
Vulnerability from github – Published: 2022-03-11 00:02 – 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-23041"
],
"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-fh24-7cc2-vrh4",
"modified": "2022-03-18T00:01:19Z",
"published": "2022-03-11T00:02:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23041"
},
{
"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-FH27-82WQ-79R2
Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26v9fs_wstat in hw/9pfs/9p.c in QEMU allows guest OS users to cause a denial of service (crash) because of a race condition during file renaming.
{
"affected": [],
"aliases": [
"CVE-2018-19489"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-13T19:29:00Z",
"severity": "MODERATE"
},
"details": "v9fs_wstat in hw/9pfs/9p.c in QEMU allows guest OS users to cause a denial of service (crash) because of a race condition during file renaming.",
"id": "GHSA-fh27-82wq-79r2",
"modified": "2022-05-13T01:26:37Z",
"published": "2022-05-13T01:26:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19489"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/153326"
},
{
"type": "WEB",
"url": "https://git.qemu.org/?p=qemu.git;a=commit;h=1d20398694a3b67a388d955b7a945ba4aa90a8a8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00023.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CGCFIFSIWUREEQQOZDZFBYKWZHXCWBZN"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04489.html"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/May/76"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2018-19489"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3923-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4454"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00042.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2018/11/26/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106007"
}
],
"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-FH74-HM69-RQJW
Vulnerability from github – Published: 2021-05-27 18:41 – Updated: 2024-05-31 17:08Impact
By crafting a malicious root filesystem (with /proc being a symlink to a directory which was inside a volume shared with another running container), an attacker in control of both containers can trick runc into not correctly configuring the container's security labels and not correctly masking paths inside /proc which contain potentially-sensitive information about the host (or even allow for direct attacks against the host).
In order to exploit this bug, an untrusted user must be able to spawn custom containers with custom mount configurations (such that a volume is shared between two containers). It should be noted that we consider this to be a fairly high level of access for an untrusted user -- and we do not recommend allowing completely untrusted users to have such degrees of access without further restrictions.
Specific Go Package Affected
github.com/opencontainers/runc/libcontainer
Patches
This vulnerability has been fixed in 1.0.0-rc10. It should be noted that the current fix is effectively a hot-fix, and there are known ways for it to be worked around (such as making the entire root filesystem a shared volume controlled by another container). We recommend that users review their access policies to ensure that untrusted users do not have such high levels of controls over container mount configuration.
Workarounds
If you are not providing the ability for untrusted users to configure mountpoints for runc (or through a higher-level tool such as docker run -v) then you are not vulnerable to this issue. This exploit requires fairly complicated levels of access (which are available for some public clouds but are not necessarily available for all deployments).
Additionally, it appears as though it is not possible to exploit this vulnerability through Docker (due to the order of mounts Docker generates). However you should not depend on this, as it may be possible to work around this roadblock.
Credits
This vulnerability was discovered by Cure53, as part of a third-party security audit.
For more information
If you have any questions or comments about this advisory: * Open an issue. * Email us at dev@opencontainers.org, or security@opencontainers.org if you think you've found a security bug.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0-rc9.0.20200122160610-2fc03cc11c77"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-19921"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-24T21:20:41Z",
"nvd_published_at": "2020-02-12T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nBy crafting a malicious root filesystem (with `/proc` being a symlink to a directory which was inside a volume shared with another running container), an attacker in control of both containers can trick `runc` into not correctly configuring the container\u0027s security labels and not correctly masking paths inside `/proc` which contain potentially-sensitive information about the host (or even allow for direct attacks against the host).\n\nIn order to exploit this bug, an untrusted user must be able to spawn custom containers with custom mount configurations (such that a volume is shared between two containers). It should be noted that we consider this to be a fairly high level of access for an untrusted user -- and we do not recommend allowing completely untrusted users to have such degrees of access without further restrictions.\n\n### Specific Go Package Affected\ngithub.com/opencontainers/runc/libcontainer\n\n### Patches\nThis vulnerability has been fixed in `1.0.0-rc10`. It should be noted that the current fix is effectively a hot-fix, and there are known ways for it to be worked around (such as making the entire root filesystem a shared volume controlled by another container). We recommend that users review their access policies to ensure that untrusted users do not have such high levels of controls over container mount configuration.\n\n### Workarounds\nIf you are not providing the ability for untrusted users to configure mountpoints for `runc` (or through a higher-level tool such as `docker run -v`) then you are not vulnerable to this issue. This exploit requires fairly complicated levels of access (which are available for some public clouds but are not necessarily available for all deployments).\n\nAdditionally, it appears as though it is not possible to exploit this vulnerability through Docker (due to the order of mounts Docker generates). However you should not depend on this, as it may be possible to work around this roadblock.\n\n### Credits\nThis vulnerability was discovered by Cure53, as part of a third-party security audit.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* [Open an issue](https://github.com/opencontainers/runc/issues/new).\n* Email us at [dev@opencontainers.org](mailto:dev@opencontainers.org), or [security@opencontainers.org](mailto:security@opencontainers.org) if you think you\u0027ve found a security bug.",
"id": "GHSA-fh74-hm69-rqjw",
"modified": "2024-05-31T17:08:04Z",
"published": "2021-05-27T18:41:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-fh74-hm69-rqjw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19921"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/issues/2197"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/pull/2190"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/pull/2207"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/2fc03cc11c775b7a8b2e48d7ee447cb9bef32ad0"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4297-1"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202003-21"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2019-19921"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2021-0087"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I6BF24VCZRFTYBTT3T7HDZUOTKOTNPLZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FYVE3GB4OG3BNT5DLQHYO4M5SXX33AQ5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FNB2UEDIIJCRQW4WJLZOPQJZXCVSXMLD"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DHGVGGMKGZSJ7YO67TGGPFEHBYMS63VF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ANUGDBJ7NBUMSUFZUSKU3ZMQYZ2Z3STN"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00023.html"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/releases"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0695"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0688"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00018.html"
}
],
"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/E:U/RL:U/RC:U",
"type": "CVSS_V3"
}
],
"summary": "opencontainers runc contains procfs race condition with a shared volume mount"
}
GHSA-FHMQ-36M9-74F3
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Shell allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-64658"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T18:16:05Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Shell allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-fhmq-36m9-74f3",
"modified": "2025-12-09T18:30:47Z",
"published": "2025-12-09T18:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64658"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-64658"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FHP6-CW2V-3RQJ
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-07 18:30In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop
A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE:
Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108
Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup:
Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50
The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function.
Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.
{
"affected": [],
"aliases": [
"CVE-2026-31728"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_ether: Fix race between gether_disconnect and eth_stop\n\nA race condition between gether_disconnect() and eth_stop() leads to a\nNULL pointer dereference. Specifically, if eth_stop() is triggered\nconcurrently while gether_disconnect() is tearing down the endpoints,\neth_stop() attempts to access the cleared endpoint descriptor, causing\nthe following NPE:\n\n Unable to handle kernel NULL pointer dereference\n Call trace:\n __dwc3_gadget_ep_enable+0x60/0x788\n dwc3_gadget_ep_enable+0x70/0xe4\n usb_ep_enable+0x60/0x15c\n eth_stop+0xb8/0x108\n\nBecause eth_stop() crashes while holding the dev-\u003elock, the thread\nrunning gether_disconnect() fails to acquire the same lock and spins\nforever, resulting in a hardlockup:\n\n Core - Debugging Information for Hardlockup core(7)\n Call trace:\n queued_spin_lock_slowpath+0x94/0x488\n _raw_spin_lock+0x64/0x6c\n gether_disconnect+0x19c/0x1e8\n ncm_set_alt+0x68/0x1a0\n composite_setup+0x6a0/0xc50\n\nThe root cause is that the clearing of dev-\u003eport_usb in\ngether_disconnect() is delayed until the end of the function.\n\nMove the clearing of dev-\u003eport_usb to the very beginning of\ngether_disconnect() while holding dev-\u003elock. This cuts off the link\nimmediately, ensuring eth_stop() will see dev-\u003eport_usb as NULL and\nsafely bail out.",
"id": "GHSA-fhp6-cw2v-3rqj",
"modified": "2026-05-07T18:30:34Z",
"published": "2026-05-01T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31728"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ad77458637b78ec655e3da5f112c862e6690a9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ff689edfeceb5e3ec1623e09af2b2aa0f1098a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a259ba0bce3b192c04334499690372a250f7d0b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbb09bb89ffa571475f66daca9482b974cd29d6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1e7a66584bf0aff3becb73c19fa31527889fc9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1eabb072c75681f78312c484ccfffb7430f206e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f02980594deef751e42133714aee25228f1494c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6813c2b2ae78def76b69e0f9d72f80e4a1c4aca"
}
],
"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.