CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
2909 vulnerabilities reference this CWE, most recent first.
GHSA-P5F2-P286-M43F
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to check atomic_file in f2fs ioctl interfaces
Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.
{
"affected": [],
"aliases": [
"CVE-2024-49859"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to check atomic_file in f2fs ioctl interfaces\n\nSome f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),\nf2fs_move_file_range(), and f2fs_defragment_range() missed to\ncheck atomic_write status, which may cause potential race issue,\nfix it.",
"id": "GHSA-p5f2-p286-m43f",
"modified": "2025-11-04T00:31:39Z",
"published": "2024-10-21T15:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10569b682ebe9c75ef06ddd322ae844e9be6374b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26b07bd2e1f124b0e430c8d250023f7205c549c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cb51731f24b216b0b87942f519f2c67a17107ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfe5c02654261bfb8bd9cb174a67f3279ea99e58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6f08c88047accc6127dddb6798a3ff11321539d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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-P5PC-67G7-QCV2
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
af_unix: Give up GC if MSG_PEEK intervened.
Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro.
This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").
After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue.
The problem is that MSG_PEEK bumps a file refcount without interacting with GC.
Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B.
The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B.
GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2
close(sk-B)
-> sk-B's file refcount : 2 -> 1
unix_vertex_dead(sk-B) -> true
Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds.
However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation.
At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former.
Finally, GC incorrectly concludes that both sk-A and sk-B are dead.
One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm.
The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection.
When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC.
Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC.
Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run.
This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily.
Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.
{
"affected": [],
"aliases": [
"CVE-2026-23394"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Give up GC if MSG_PEEK intervened.\n\nIgor Ushakov reported that GC purged the receive queue of\nan alive socket due to a race with MSG_PEEK with a nice repro.\n\nThis is the exact same issue previously fixed by commit\ncbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\").\n\nAfter GC was replaced with the current algorithm, the cited\ncommit removed the locking dance in unix_peek_fds() and\nreintroduced the same issue.\n\nThe problem is that MSG_PEEK bumps a file refcount without\ninteracting with GC.\n\nConsider an SCC containing sk-A and sk-B, where sk-A is\nclose()d but can be recv()ed via sk-B.\n\nThe bad thing happens if sk-A is recv()ed with MSG_PEEK from\nsk-B and sk-B is close()d while GC is checking unix_vertex_dead()\nfor sk-A and sk-B.\n\n GC thread User thread\n --------- -----------\n unix_vertex_dead(sk-A)\n -\u003e true \u003c------.\n \\\n `------ recv(sk-B, MSG_PEEK)\n invalidate !! -\u003e sk-A\u0027s file refcount : 1 -\u003e 2\n\n close(sk-B)\n -\u003e sk-B\u0027s file refcount : 2 -\u003e 1\n unix_vertex_dead(sk-B)\n -\u003e true\n\nInitially, sk-A\u0027s file refcount is 1 by the inflight fd in sk-B\nrecvq. GC thinks sk-A is dead because the file refcount is the\nsame as the number of its inflight fds.\n\nHowever, sk-A\u0027s file refcount is bumped silently by MSG_PEEK,\nwhich invalidates the previous evaluation.\n\nAt this moment, sk-B\u0027s file refcount is 2; one by the open fd,\nand one by the inflight fd in sk-A. The subsequent close()\nreleases one refcount by the former.\n\nFinally, GC incorrectly concludes that both sk-A and sk-B are dead.\n\nOne option is to restore the locking dance in unix_peek_fds(),\nbut we can resolve this more elegantly thanks to the new algorithm.\n\nThe point is that the issue does not occur without the subsequent\nclose() and we actually do not need to synchronise MSG_PEEK with\nthe dead SCC detection.\n\nWhen the issue occurs, close() and GC touch the same file refcount.\nIf GC sees the refcount being decremented by close(), it can just\ngive up garbage-collecting the SCC.\n\nTherefore, we only need to signal the race during MSG_PEEK with\na proper memory barrier to make it visible to the GC.\n\nLet\u0027s use seqcount_t to notify GC when MSG_PEEK occurs and let\nit defer the SCC to the next run.\n\nThis way no locking is needed on the MSG_PEEK side, and we can\navoid imposing a penalty on every MSG_PEEK unnecessarily.\n\nNote that we can retry within unix_scc_dead() if MSG_PEEK is\ndetected, but we do not do so to avoid hung task splat from\nabusive MSG_PEEK calls.",
"id": "GHSA-p5pc-67g7-qcv2",
"modified": "2026-06-01T18:31:22Z",
"published": "2026-03-25T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23394"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3106f326f67c03dd9da4ca64663d11e40138cf40"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37dd7ab332396eb8dd80b2dc7ea4b61abf767436"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72cf49ad50c16270b52bc512d9c2df5743922968"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3dd56fb5683ba80bf8d7a2f9aa21cfa53f05202"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5b31d988a41549037b8d8721a3c3cae893d8670"
}
],
"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-P5RF-W8RC-H46H
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Telephony Service allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-42912"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:11Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Telephony Service allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-p5rf-w8rc-h46h",
"modified": "2026-06-09T18:30:44Z",
"published": "2026-06-09T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42912"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42912"
}
],
"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-P5W2-MXXH-JWGH
Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-25 00:00In ipu_core_jqs_msg_transport_kernel_write_sync of ipu-core-jqs-msg-transport.c, 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 kernelAndroid ID: A-176754369References: N/A
{
"affected": [],
"aliases": [
"CVE-2022-20155"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-15T14:15:00Z",
"severity": "HIGH"
},
"details": "In ipu_core_jqs_msg_transport_kernel_write_sync of ipu-core-jqs-msg-transport.c, 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 kernelAndroid ID: A-176754369References: N/A",
"id": "GHSA-p5w2-mxxh-jwgh",
"modified": "2022-06-25T00:00:59Z",
"published": "2022-06-16T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20155"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-06-01"
}
],
"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-P62G-JHG6-V3RQ
Vulnerability from github – Published: 2021-04-07 20:37 – Updated: 2024-11-18 16:26A flaw was found in Ansible Engine, all versions 2.7.x, 2.8.x and 2.9.x prior to 2.7.17, 2.8.11, and 2.9.7 respectively, when using ansible_facts as a subkey of itself and promoting it to a variable when inject is enabled, overwriting the ansible_facts after the clean. An attacker could take advantage of this by altering the ansible_facts, such as ansible_hosts, users and any other key data which would lead into privilege escalation or code injection.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0a1"
},
{
"fixed": "2.7.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0a1"
},
{
"fixed": "2.8.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0a1"
},
{
"fixed": "2.9.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-10684"
],
"database_specific": {
"cwe_ids": [
"CWE-250",
"CWE-362",
"CWE-862",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-05T14:46:48Z",
"nvd_published_at": "2020-03-24T14:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Ansible Engine, all versions 2.7.x, 2.8.x and 2.9.x prior to 2.7.17, 2.8.11, and 2.9.7 respectively, when using ansible_facts as a subkey of itself and promoting it to a variable when inject is enabled, overwriting the ansible_facts after the clean. An attacker could take advantage of this by altering the ansible_facts, such as ansible_hosts, users and any other key data which would lead into privilege escalation or code injection.",
"id": "GHSA-p62g-jhg6-v3rq",
"modified": "2024-11-18T16:26:11Z",
"published": "2021-04-07T20:37:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10684"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/commit/0b4788a71fc7d24ffa957a94ee5e23d6a9733ab0"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/commit/1d0d2645eed36ac4e17052ab4eacf240132d96fb"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/commit/5eabf7bb93c9bfc375b806a2b1f623d650cddc2b"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/commit/a9d2ceafe429171c0e2ad007058b88bae57c74ce"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10684"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-p62g-jhg6-v3rq"
},
{
"type": "PACKAGE",
"url": "https://github.com/ansible/ansible"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/ansible/PYSEC-2020-207.yaml"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DKPA4KC3OJSUFASUYMG66HKJE7ADNGFW"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MRRYUU5ZBLPBXCYG6CFP35D64NP2UB2S"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WQVOQD4VAIXXTVQAJKTN7NUGTJFE2PCB"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202006-11"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4950"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Code Injection, Race Condition, and Execution with Unnecessary Privileges in Ansible"
}
GHSA-P65G-P74P-9MVQ
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-20924"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T18:16:19Z",
"severity": "HIGH"
},
"details": "Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-p65g-p74p-9mvq",
"modified": "2026-01-13T18:31:10Z",
"published": "2026-01-13T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20924"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20924"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P672-9QR7-4CMF
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2025-12-23 18:30In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put().
Example A:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(...
Example B:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(...
Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
{
"affected": [],
"aliases": [
"CVE-2024-27005"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Don\u0027t access req_list while it\u0027s being manipulated\n\nThe icc_lock mutex was split into separate icc_lock and icc_bw_lock\nmutexes in [1] to avoid lockdep splats. However, this didn\u0027t adequately\nprotect access to icc_node::req_list.\n\nThe icc_set_bw() function will eventually iterate over req_list while\nonly holding icc_bw_lock, but req_list can be modified while only\nholding icc_lock. This causes races between icc_set_bw(), of_icc_get(),\nand icc_put().\n\nExample A:\n\n CPU0 CPU1\n ---- ----\n icc_set_bw(path_a)\n mutex_lock(\u0026icc_bw_lock);\n icc_put(path_b)\n mutex_lock(\u0026icc_lock);\n aggregate_requests()\n hlist_for_each_entry(r, ...\n hlist_del(...\n \u003cr = invalid pointer\u003e\n\nExample B:\n\n CPU0 CPU1\n ---- ----\n icc_set_bw(path_a)\n mutex_lock(\u0026icc_bw_lock);\n path_b = of_icc_get()\n of_icc_get_by_index()\n mutex_lock(\u0026icc_lock);\n path_find()\n path_init()\n aggregate_requests()\n hlist_for_each_entry(r, ...\n hlist_add_head(...\n \u003cr = invalid pointer\u003e\n\nFix this by ensuring icc_bw_lock is always held before manipulating\nicc_node::req_list. The additional places icc_bw_lock is held don\u0027t\nperform any memory allocations, so we should still be safe from the\noriginal lockdep splats that motivated the separate locks.\n\n[1] commit af42269c3523 (\"interconnect: Fix locking for runpm vs reclaim\")",
"id": "GHSA-p672-9qr7-4cmf",
"modified": "2025-12-23T18:30:18Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27005"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P6C9-G8CQ-8FC7
Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-05 18:31In multiple locations, there is a possible way to use apps linked from a context menu of a lockscreen app 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.
{
"affected": [],
"aliases": [
"CVE-2025-48533"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-04T19:15:39Z",
"severity": "HIGH"
},
"details": "In multiple locations, there is a possible way to use apps linked from a context menu of a lockscreen app 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.",
"id": "GHSA-p6c9-g8cq-8fc7",
"modified": "2025-09-05T18:31:19Z",
"published": "2025-09-04T21:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48533"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-08-01"
}
],
"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-P6QW-9QH6-CC5X
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Services Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49119"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-843"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:38Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Services Remote Code Execution Vulnerability",
"id": "GHSA-p6qw-9qh6-cc5x",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49119"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49119"
}
],
"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"
}
]
}
GHSA-P739-C89Q-VJ36
Vulnerability from github – Published: 2024-08-06 18:30 – Updated: 2024-08-08 00:31Race in Frames in Google Chrome prior to 127.0.6533.72 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2024-6996"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-06T16:15:50Z",
"severity": "LOW"
},
"details": "Race in Frames in Google Chrome prior to 127.0.6533.72 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-p739-c89q-vj36",
"modified": "2024-08-08T00:31:44Z",
"published": "2024-08-06T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6996"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2024/07/stable-channel-update-for-desktop_23.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/333708039"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
"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.