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.
3211 vulnerabilities reference this CWE, most recent first.
GHSA-XHF3-PP4Q-GXH5
Vulnerability from github – Published: 2024-06-17 18:31 – Updated: 2025-11-04 00:30A defect was discovered in the Python “ssl” module where there is a memory race condition with the ssl.SSLContext methods “cert_store_stats()” and “get_ca_certs()”. The race condition can be triggered if the methods are called at the same time as certificates are loaded into the SSLContext, such as during the TLS handshake with a certificate directory configured. This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.
{
"affected": [],
"aliases": [
"CVE-2024-0397"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-17T16:15:10Z",
"severity": "HIGH"
},
"details": "A defect was discovered in the Python \u201cssl\u201d module where there is a memory\nrace condition with the ssl.SSLContext methods \u201ccert_store_stats()\u201d and\n\u201cget_ca_certs()\u201d. The race condition can be triggered if the methods are\ncalled at the same time as certificates are loaded into the SSLContext,\nsuch as during the TLS handshake with a certificate directory configured.\nThis issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.",
"id": "GHSA-xhf3-pp4q-gxh5",
"modified": "2025-11-04T00:30:49Z",
"published": "2024-06-17T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0397"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/114572"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/114573"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/01c37f1d0714f5822d34063ca7180b595abf589d"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/29c97287d205bf2f410f4895ebce3f43b5160524"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/37324b421b72b7bc9934e27aba85d48d4773002e"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/542f3272f56f31ed04e74c40635a913fbc12d286"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/b228655c227b2ca298a8ffac44d14ce3d22f6faa"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/bce693111bff906ccf9281c22371331aaff766ab"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00000.html"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/BMAK5BCGKYWNJOACVUSLUF6SFGBIM4VP"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250411-0006"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/06/17/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XHMM-RP2Q-VM34
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05In wrapUserThread of AudioStream.cpp, 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: AndroidVersions: Android-11Android ID: A-174801970
{
"affected": [],
"aliases": [
"CVE-2021-0565"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-22T11:15:00Z",
"severity": "HIGH"
},
"details": "In wrapUserThread of AudioStream.cpp, 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: AndroidVersions: Android-11Android ID: A-174801970",
"id": "GHSA-xhmm-rp2q-vm34",
"modified": "2022-05-24T19:05:56Z",
"published": "2022-05-24T19:05:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0565"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2021-06-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XHW3-H8GQ-2W23
Vulnerability from github – Published: 2024-10-29 15:32 – Updated: 2024-10-29 18:30Potential race conditions in IndexedDB could have caused memory corruption, leading to a potentially exploitable crash. This vulnerability affects Firefox < 132 and Thunderbird < 132.
{
"affected": [],
"aliases": [
"CVE-2024-10468"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-29T13:15:04Z",
"severity": "CRITICAL"
},
"details": "Potential race conditions in IndexedDB could have caused memory corruption, leading to a potentially exploitable crash. This vulnerability affects Firefox \u003c 132 and Thunderbird \u003c 132.",
"id": "GHSA-xhw3-h8gq-2w23",
"modified": "2024-10-29T18:30:36Z",
"published": "2024-10-29T15:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10468"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1914982"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-55"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-59"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XJ3H-WWXQ-GFCJ
Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40Summary
Cloudreve v4 splits the storage-quota check (reading the user's used bytes and comparing them to MaxStorage) and the charge (incrementing users.storage) into two non-atomic steps in the PrepareUpload code path. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Any authenticated user — including an unprivileged account in the default User group — can concurrently issue several upload-session requests that all read the same stale used snapshot, each pass the check, and then each contribute their declared size to users.storage. The end result is that the total approved capacity exceeds the group's MaxStorage many times over.
The same primitive is trivially amplifiable into a storage-based denial of service. During PrepareUpload, Cloudreve reserves the declared size against users.storage before any bytes are written, so an attacker can push the reserved amount far beyond the host's physical disk (tested: a 1 GiB-quota account reserved 17 GiB in a single 20-way burst), and can then materialise the reservation by completing chunked uploads to actually write the excess bytes to disk. Amplification to the host's free space fills the disk and denies uploads for every user of the instance.
Exploitation requires only a valid session with Files.Write permission. No administrator configuration, no non-default storage policy, and no elevated privileges are needed. The default deployment (local storage policy, default User group) is affected.
Technical details
PrepareUpload in pkg/filemanager/fs/dbfs/upload.go splits quota enforcement across two stages:
Stage A — the check (snapshot compare, no lock) — pkg/filemanager/fs/dbfs/validator.go:
func (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error {
capacity, err := f.Capacity(ctx, u) // reads "used"
if err != nil { return ... }
return f.validateUserCapacityRaw(ctx, size, capacity)
}
func (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error {
if capacity.Used + size > capacity.Total { // snapshot compare only; no lock, no reservation
return fs.ErrInsufficientCapacity
}
return nil
}
capacity.Used comes from the in-memory *ent.User that was hydrated once at the beginning of the request — pkg/filemanager/fs/dbfs/dbfs.go:
func (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) {
...
res.Used = f.user.Storage // captured at request start
res.Total = requesterGroup.MaxStorage
return res, nil
}
No SELECT is issued at check time, no row lock is taken on the user row, and pending upload sessions are not counted.
Stage B — the charge (single unconditional UPDATE, outside the tx) — pkg/filemanager/fs/dbfs/upload.go → inventory/tx.go → inventory/user.go:
// PrepareUpload: check (A) ... then, many statements later ...
if err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil {
return nil, err
}
...
if err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... } // charge (B)
// inventory/user.go
c.client.User.Update().Where(user.ID(uid)).AddStorage(diff).Exec(ctx) // SQL: storage = storage + diff
Between A and B the code performs storage-policy load-balancing, save-path generation, encryption-metadata generation, transaction start, placeholder-file/entity creation, and metadata upsert. This leaves a wide race window. N concurrent PrepareUpload requests each read the same stale Used snapshot at A, each pass their independent quota check, and then each add their own size to users.storage at B. The committed total is up to N × size above MaxStorage.
Three defensive controls that would each independently close the race are missing:
- The check and the charge are not enclosed in the same transaction with a
SELECT ... FOR UPDATEon the user row. - The charge is a plain
storage = storage + :sizeUPDATE, not an atomic conditional update of the formUPDATE users SET storage = storage + :size WHERE id = :uid AND storage + :size <= :max_storage. Usedis computed only from committed entities. Concurrent pending upload sessions (which have already been reserved by the accounting model) are not counted, so races among sessions that haven't yet completed are invisible to each other.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260715025621-7329602751c0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77633"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:40:33Z",
"nvd_published_at": "2026-09-22T16:17:55Z",
"severity": "HIGH"
},
"details": "## Summary\n\nCloudreve v4 splits the storage-quota **check** (reading the user\u0027s `used` bytes and comparing them to `MaxStorage`) and the **charge** (incrementing `users.storage`) into two non-atomic steps in the `PrepareUpload` code path. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Any authenticated user \u2014 including an unprivileged account in the default `User` group \u2014 can concurrently issue several upload-session requests that all read the same stale `used` snapshot, each pass the check, and then each contribute their declared `size` to `users.storage`. The end result is that the total approved capacity exceeds the group\u0027s `MaxStorage` many times over.\n\nThe same primitive is trivially amplifiable into a storage-based denial of service. During `PrepareUpload`, Cloudreve reserves the declared size against `users.storage` before any bytes are written, so an attacker can push the reserved amount far beyond the host\u0027s physical disk (tested: a 1 GiB-quota account reserved 17 GiB in a single 20-way burst), and can then materialise the reservation by completing chunked uploads to actually write the excess bytes to disk. Amplification to the host\u0027s free space fills the disk and denies uploads for every user of the instance.\n\nExploitation requires only a valid session with `Files.Write` permission. No administrator configuration, no non-default storage policy, and no elevated privileges are needed. The default deployment (local storage policy, default `User` group) is affected.\n\n## Technical details\n\n`PrepareUpload` in `pkg/filemanager/fs/dbfs/upload.go` splits quota enforcement across two stages:\n\n**Stage A \u2014 the check (snapshot compare, no lock)** \u2014 `pkg/filemanager/fs/dbfs/validator.go`:\n\n```go\nfunc (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error {\n capacity, err := f.Capacity(ctx, u) // reads \"used\"\n if err != nil { return ... }\n return f.validateUserCapacityRaw(ctx, size, capacity)\n}\n\nfunc (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error {\n if capacity.Used + size \u003e capacity.Total { // snapshot compare only; no lock, no reservation\n return fs.ErrInsufficientCapacity\n }\n return nil\n}\n```\n\n`capacity.Used` comes from the in-memory `*ent.User` that was hydrated once at the beginning of the request \u2014 `pkg/filemanager/fs/dbfs/dbfs.go`:\n\n```go\nfunc (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) {\n ...\n res.Used = f.user.Storage // captured at request start\n res.Total = requesterGroup.MaxStorage\n return res, nil\n}\n```\n\nNo SELECT is issued at check time, no row lock is taken on the user row, and pending upload sessions are not counted.\n\n**Stage B \u2014 the charge (single unconditional UPDATE, outside the tx)** \u2014 `pkg/filemanager/fs/dbfs/upload.go` \u2192 `inventory/tx.go` \u2192 `inventory/user.go`:\n\n```go\n// PrepareUpload: check (A) ... then, many statements later ...\nif err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil {\n return nil, err\n}\n...\nif err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... } // charge (B)\n\n// inventory/user.go\nc.client.User.Update().Where(user.ID(uid)).AddStorage(diff).Exec(ctx) // SQL: storage = storage + diff\n```\n\nBetween A and B the code performs storage-policy load-balancing, save-path generation, encryption-metadata generation, transaction start, placeholder-file/entity creation, and metadata upsert. This leaves a wide race window. `N` concurrent `PrepareUpload` requests each read the same stale `Used` snapshot at A, each pass their independent quota check, and then each add their own `size` to `users.storage` at B. The committed total is up to `N \u00d7 size` above `MaxStorage`.\n\nThree defensive controls that would each independently close the race are missing:\n\n1. The check and the charge are not enclosed in the same transaction with a `SELECT ... FOR UPDATE` on the user row.\n2. The charge is a plain `storage = storage + :size` UPDATE, not an atomic conditional update of the form `UPDATE users SET storage = storage + :size WHERE id = :uid AND storage + :size \u003c= :max_storage`.\n3. `Used` is computed only from committed entities. Concurrent pending upload sessions (which have already been reserved by the accounting model) are not counted, so races among sessions that haven\u0027t yet completed are invisible to each other.",
"id": "GHSA-xj3h-wwxq-gfcj",
"modified": "2026-09-22T20:40:33Z",
"published": "2026-09-22T20:40:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-xj3h-wwxq-gfcj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77633"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/7329602751c00bb4136fe9ad8b364d0df70773df"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service"
}
GHSA-XJ3V-8P9P-J8Q5
Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31In the Linux kernel, the following vulnerability has been resolved:
ip: Fix a data-race around sysctl_fwmark_reflect.
While reading sysctl_fwmark_reflect, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
{
"affected": [],
"aliases": [
"CVE-2022-49602"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nip: Fix a data-race around sysctl_fwmark_reflect.\n\nWhile reading sysctl_fwmark_reflect, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.",
"id": "GHSA-xj3v-8p9p-j8q5",
"modified": "2025-03-12T00:31:46Z",
"published": "2025-03-12T00:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49602"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ee76fe01ff3c0b4efaa500aecc90d7c8d3a8860"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25a635a67c830766110410fea88ec4e6ee29684b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e7a1be3e68deef250ad43cc91f7bb8d7d758b48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9096edcf4854289f92252e086cf6e498c7f8c21d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a475ecc9ad919aa3ebdd4e4a6ee612b793bf74b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dccf8a67f30e18980d13f07006e5a536bbd1e136"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc92e3b4bebfdd986ef1d2c5019f236837b0b982"
}
],
"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-XJX8-665X-J9WH
Vulnerability from github – Published: 2022-07-22 00:00 – Updated: 2022-07-28 00:00A race condition in the Linux kernel before 5.6.2 between the VT_DISALLOCATE ioctl and closing/opening of ttys could lead to a use-after-free.
{
"affected": [],
"aliases": [
"CVE-2020-36557"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-21T04:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition in the Linux kernel before 5.6.2 between the VT_DISALLOCATE ioctl and closing/opening of ttys could lead to a use-after-free.",
"id": "GHSA-xjx8-665x-j9wh",
"modified": "2022-07-28T00:00:41Z",
"published": "2022-07-22T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36557"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.6.2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ca4463bf8438b403596edd0ec961ca0d4fbe0220"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XM6W-HHCM-7V7G
Vulnerability from github – Published: 2022-05-02 06:15 – Updated: 2022-05-02 06:15gdk/gdkwindow.c in GTK+ before 2.18.5, as used in gnome-screensaver before 2.28.1, performs implicit paints on windows of type GDK_WINDOW_FOREIGN, which triggers an X error in certain circumstances and consequently allows physically proximate attackers to bypass screen locking and access an unattended workstation by pressing the Enter key many times.
{
"affected": [],
"aliases": [
"CVE-2010-0732"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-03-19T19:30:00Z",
"severity": "MODERATE"
},
"details": "gdk/gdkwindow.c in GTK+ before 2.18.5, as used in gnome-screensaver before 2.28.1, performs implicit paints on windows of type GDK_WINDOW_FOREIGN, which triggers an X error in certain circumstances and consequently allows physically proximate attackers to bypass screen locking and access an unattended workstation by pressing the Enter key many times.",
"id": "GHSA-xm6w-hhcm-7v7g",
"modified": "2022-05-02T06:15:12Z",
"published": "2022-05-02T06:15:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-0732"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2010-0732"
},
{
"type": "WEB",
"url": "https://bugs.edge.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/446395"
},
{
"type": "WEB",
"url": "https://bugzilla.gnome.org/show_bug.cgi?id=598476"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=565527"
},
{
"type": "WEB",
"url": "http://ftp.gnome.org/pub/gnome/sources/gtk+/2.18/gtk+-2.18.5.news"
},
{
"type": "WEB",
"url": "http://git.gnome.org/browse/gnome-screensaver/commit/?h=gnome-2-28\u0026id=98f8a22412cf388217fd5b88915eadd274d68520"
},
{
"type": "WEB",
"url": "http://git.gnome.org/browse/gnome-screensaver/commit/?id=ab08cc93f2dc6223c8c00bfa1ca4f2d89069dbe0"
},
{
"type": "WEB",
"url": "http://git.gnome.org/browse/gtk+/commit/?id=0748cf563d0d0d03001a62589f13be16a8ec06c1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2010-04/msg00001.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/39317"
},
{
"type": "WEB",
"url": "http://www.heise.de/newsticker/meldung/Gnome-Bildschirmsperre-in-OpenSuse-Linux-wirkungslos-2-Update-928580.html"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2010:109"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/02/12/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/03/05/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/03/16/9"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/38211"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XMHH-M2J3-CR44
Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Projected File System allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-27927"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T18:17:03Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Projected File System allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-xmhh-m2j3-cr44",
"modified": "2026-04-14T18:30:39Z",
"published": "2026-04-14T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27927"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-27927"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XMMH-RRMP-Q4M2
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-23039"
],
"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-xmmh-rrmp-q4m2",
"modified": "2022-03-18T00:01:19Z",
"published": "2022-03-11T00:02:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23039"
},
{
"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-XMX9-537G-PR66
Vulnerability from github – Published: 2026-08-03 21:31 – Updated: 2026-08-07 15:33A race condition exists in the cloud-based Omada device adoption process when an attacker may be able to interact with the adoption workflow before a legitimate device completes registration, resulting in provisioning information being delivered to an attacker.
Successful exploitation may allow disclosure of provisioning information intended for a legitimate device.
{
"affected": [],
"aliases": [
"CVE-2025-15630"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-03T19:16:40Z",
"severity": "MODERATE"
},
"details": "A race\ncondition exists in the cloud-based Omada device adoption process when an\nattacker may be able to interact with the adoption workflow before a legitimate\ndevice completes registration, resulting in provisioning information being\ndelivered to an attacker.\n\n\n\n\n\n\n\n\n\nSuccessful\nexploitation may allow disclosure of provisioning information intended for a\nlegitimate device.",
"id": "GHSA-xmx9-537g-pr66",
"modified": "2026-08-07T15:33:06Z",
"published": "2026-08-03T21:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15630"
},
{
"type": "WEB",
"url": "https://www.omadanetworks.com/en/support/download"
},
{
"type": "WEB",
"url": "https://www.omadanetworks.com/us/support/download"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/faq/5216"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/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"
}
]
}
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.