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.
3627 vulnerabilities reference this CWE, most recent first.
GHSA-F2F7-QFWQ-94J2
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a data-race around bpf_jit_limit.
While reading bpf_jit_limit, it can be changed concurrently via sysctl, WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit is long, so we need to add a paired READ_ONCE() to avoid load-tearing.
{
"affected": [],
"aliases": [
"CVE-2022-49967"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a data-race around bpf_jit_limit.\n\nWhile reading bpf_jit_limit, it can be changed concurrently via sysctl,\nWRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit\nis long, so we need to add a paired READ_ONCE() to avoid load-tearing.",
"id": "GHSA-f2f7-qfwq-94j2",
"modified": "2025-11-14T18:31:23Z",
"published": "2025-06-18T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49967"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0947ae1121083d363d522ff7518ee72b55bd8d29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba632ad0bacb13197a8f38e7526448974e87f292"
}
],
"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-F2RM-CRH3-7XRR
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-21221"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T18:16:24Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-f2rm-crh3-7xrr",
"modified": "2026-01-13T18:31:11Z",
"published": "2026-01-13T18:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21221"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21221"
}
],
"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-F2X7-CMM5-V9RH
Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_migrate_req.
While reading sysctl_tcp_migrate_req, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
{
"affected": [],
"aliases": [
"CVE-2022-49588"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_migrate_req.\n\nWhile reading sysctl_tcp_migrate_req, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.",
"id": "GHSA-f2x7-cmm5-v9rh",
"modified": "2025-03-10T21:31:11Z",
"published": "2025-03-10T21:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49588"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4177f545895b1da08447a80692f30617154efa6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e569a11eea20a1ccebc3c4e6366bf0574a449e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcf6c6d8aeffebca66f37b17ef1b57112e5e09c1"
}
],
"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-F32V-F53X-625G
Vulnerability from github – Published: 2022-05-17 02:08 – Updated: 2022-05-17 02:08Race condition in Passcode Lock in Apple iOS before 4 on the iPhone and iPod touch allows physically proximate attackers to bypass intended passcode requirements, and pair a locked device with a computer and access arbitrary data, via vectors involving the initial boot.
{
"affected": [],
"aliases": [
"CVE-2010-1775"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-06-22T20:30:00Z",
"severity": "LOW"
},
"details": "Race condition in Passcode Lock in Apple iOS before 4 on the iPhone and iPod touch allows physically proximate attackers to bypass intended passcode requirements, and pair a locked device with a computer and access arbitrary data, via vectors involving the initial boot.",
"id": "GHSA-f32v-f53x-625g",
"modified": "2022-05-17T02:08:18Z",
"published": "2022-05-17T02:08:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-1775"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/59637"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2010/Jun/msg00003.html"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4225"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/41016"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F3FJ-9625-RV3M
Vulnerability from github – Published: 2026-10-30 14:53 – Updated: 2026-10-30 14:53Summary
Soft Serve cached repository records in memory with no expiry, and trusted the cached record for every access check. SetPrivate cleared the cached record before it saved the new visibility, and not afterwards.
A request that arrived between the two read the old, public record from the database and cached it after the change was saved. From then on every access check used that stale record, so a repository the operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.
Impact
An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.
The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.
Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.
Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.
Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).
Root Cause
The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.
Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.
SetPrivate ran in this order:
d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
... writes or removes git-daemon-export-ok ...
return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})
A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.
SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.
Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.
Affected Versions
v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.
Patches
Fixed in v0.12.3.
The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.
Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.
The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.
Workarounds
It is recommended to upgrade to the patched release.
No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/charmbracelet/soft-serve"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "0.12.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T14:53:57Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nSoft Serve cached repository records in memory with no expiry, and trusted the cached record for every access check. `SetPrivate` cleared the cached record before it saved the new visibility, and not afterwards.\n\nA request that arrived between the two read the old, public record from the database and cached it after the change was saved. From then on every access check used that stale record, so a repository the operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and `git://` until the server restarted.\n\n## Impact\n\nAn unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling `GET /\u003crepo\u003e.git/info/refs?service=git-upload-pack`, which the default `anon-access: read-only` allows, will eventually land in the window when the operator changes the visibility.\n\nThe stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. `repo private \u003cname\u003e` reads the database directly and reports `true`, and the `visibility_change` webhook is not sent, because its check reads the same stale record.\n\nWrite access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.\n\nDeployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.\n\nReachable over HTTP, SSH, and `git://` (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator\u0027s change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).\n\n## Root Cause\n\nThe cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.\n\n`Backend.Repository` in `pkg/backend/repo.go` returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (`pkg/backend/cache.go`), and `AccessLevelForUser` read the private flag from that record.\n\n`SetPrivate` ran in this order:\n\n```go\nd.cache.Delete(name)\n... d.db.TransactionContext(ctx, func(tx *db.Tx) error {\n\t... writes or removes git-daemon-export-ok ...\n\treturn d.store.SetRepoIsPrivateByName(ctx, tx, name, private)\n})\n```\n\nA reader that missed the cache after the `Delete` but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.\n\n`SetHidden`, `SetMirror`, `SetDescription`, and `SetProjectName` cleared the cache in the same place. `DeleteRepository` and `RenameRepository` deferred the clear inside the transaction function, which also runs before the commit.\n\nMoving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.\n\n## Affected Versions\n\nv0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit `e398b4d` (`refactor: implement database module and abstract backend`, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.\n\n## Patches\n\nFixed in `v0.12.3`.\n\nThe repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.\n\nRemoving the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.\n\nThe `visibility_change` webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.\n\n## Workarounds\n\nIt is recommended to upgrade to the patched release.\n\nNo configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (`repo create -p`) rather than making public ones private, and avoid changing visibility while the server is serving traffic.",
"id": "GHSA-f3fj-9625-rv3m",
"modified": "2026-10-30T14:53:57Z",
"published": "2026-10-30T14:53:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-f3fj-9625-rv3m"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/0a4e6f0b7e063927c7128756e1c1b3db871edabf"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/5b307b4da4db285f797cc028b381ba4d3d853019"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/e398b4dde723437f637b06710e0938d349b360e8"
},
{
"type": "PACKAGE",
"url": "https://github.com/charmbracelet/soft-serve"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/releases/tag/v0.12.3"
}
],
"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"
}
],
"summary": "charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users"
}
GHSA-F3H9-555P-X843
Vulnerability from github – Published: 2022-05-14 02:22 – Updated: 2023-01-26 18:30Race condition in Adobe Flash Player before 18.0.0.366 and 19.x through 22.x before 22.0.0.209 on Windows and OS X and before 11.2.202.632 on Linux allows attackers to obtain sensitive information via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2016-4247"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-07-13T02:00:00Z",
"severity": "MODERATE"
},
"details": "Race condition in Adobe Flash Player before 18.0.0.366 and 19.x through 22.x before 22.0.0.209 on Windows and OS X and before 11.2.202.632 on Linux allows attackers to obtain sensitive information via unspecified vectors.",
"id": "GHSA-f3h9-555p-x843",
"modified": "2023-01-26T18:30:47Z",
"published": "2022-05-14T02:22:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4247"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1423"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-093"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/flash-player/apsb16-25.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201607-03"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-07/msg00016.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-07/msg00017.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/91720"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1036280"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F3W2-GCGX-QW4P
Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix data-races around sysctl_tcp_fastopen.
While reading sysctl_tcp_fastopen, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
{
"affected": [],
"aliases": [
"CVE-2022-49586"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_fastopen.\n\nWhile reading sysctl_tcp_fastopen, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.",
"id": "GHSA-f3w2-gcgx-qw4p",
"modified": "2025-03-10T21:31:11Z",
"published": "2025-03-10T21:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49586"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03da610696a32578fc4f986479341ce9d430df08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22938534c611136f35e2ca545bb668073ca5ef49"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25d53d858a6c0b89a6e69e376c2a57c4f4c2c8cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/448ab998947996a0a451f8229f19087964cf2670"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/539d9ab79eba3974b479cad61a8688c41fe62e12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a54213318c43f4009ae158347aa6016e3b9b55a"
}
],
"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-F3WJ-CV4W-9CVW
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:04In the Easel driver, there is possible memory corruption due to race conditions. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-112309571
{
"affected": [],
"aliases": [
"CVE-2019-2188"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-27T19:15:00Z",
"severity": "MODERATE"
},
"details": "In the Easel driver, there is possible memory corruption due to race conditions. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-112309571",
"id": "GHSA-f3wj-cv4w-9cvw",
"modified": "2024-04-04T02:04:08Z",
"published": "2022-05-24T16:57:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-2188"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2019-09-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F439-6PJ6-2532
Vulnerability from github – Published: 2022-05-17 02:20 – Updated: 2022-05-17 02:20aRts 1.5.10 and kdelibs3 3.5.10 and earlier do not properly create temporary directories, which allows local users to hijack the IPC by pre-creating the temporary directory.
{
"affected": [],
"aliases": [
"CVE-2015-7543"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-25T14:29:00Z",
"severity": "HIGH"
},
"details": "aRts 1.5.10 and kdelibs3 3.5.10 and earlier do not properly create temporary directories, which allows local users to hijack the IPC by pre-creating the temporary directory.",
"id": "GHSA-f439-6pj6-2532",
"modified": "2022-05-17T02:20:43Z",
"published": "2022-05-17T02:20:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7543"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1280543"
}
],
"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-F49W-6988-3GR2
Vulnerability from github – Published: 2022-05-17 00:30 – Updated: 2025-04-20 03:37An issue was discovered in certain Apple products. macOS before 10.12.5 is affected. The issue involves the "DiskArbitration" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.
{
"affected": [],
"aliases": [
"CVE-2017-2533"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-22T05:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in certain Apple products. macOS before 10.12.5 is affected. The issue involves the \"DiskArbitration\" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.",
"id": "GHSA-f49w-6988-3gr2",
"modified": "2025-04-20T03:37:58Z",
"published": "2022-05-17T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2533"
},
{
"type": "WEB",
"url": "https://phoenhex.re/2017-06-09/pwn2own-diskarbitrationd-privesc"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207797"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/42146"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038484"
},
{
"type": "WEB",
"url": "http://www.zerodayinitiative.com/advisories/ZDI-17-357"
}
],
"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"
}
]
}
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.