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.
2915 vulnerabilities reference this CWE, most recent first.
GHSA-P4C6-77GC-694X
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2025-04-09 15:21The session fixation protection mechanism in cgi_process.rb in Rails 1.2.4, as used in Ruby on Rails, removes the :cookie_only attribute from the DEFAULT_SESSION_OPTIONS constant, which effectively causes cookie_only to be applied only to the first instantiation of CgiRequest, which allows remote attackers to conduct session fixation attacks. NOTE: this is due to an incomplete fix for CVE-2007-5380.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rails"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2007-6077"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:47:57Z",
"nvd_published_at": "2007-11-21T21:46:00Z",
"severity": "MODERATE"
},
"details": "The session fixation protection mechanism in cgi_process.rb in Rails 1.2.4, as used in Ruby on Rails, removes the :cookie_only attribute from the DEFAULT_SESSION_OPTIONS constant, which effectively causes cookie_only to be applied only to the first instantiation of CgiRequest, which allows remote attackers to conduct session fixation attacks. NOTE: this is due to an incomplete fix for CVE-2007-5380.",
"id": "GHSA-p4c6-77gc-694x",
"modified": "2025-04-09T15:21:26Z",
"published": "2017-10-24T18:33:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6077"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-p4c6-77gc-694x"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rails/CVE-2007-6077.yml"
},
{
"type": "WEB",
"url": "https://rubyonrails.org/2007/11/24/ruby-on-rails-1-2-6-security-and-maintenance-release"
},
{
"type": "WEB",
"url": "http://dev.rubyonrails.org/changeset/8177"
},
{
"type": "WEB",
"url": "http://dev.rubyonrails.org/ticket/10048"
},
{
"type": "WEB",
"url": "http://docs.info.apple.com/article.html?artnum=307179"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2007/Dec/msg00002.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27781"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/28136"
},
{
"type": "WEB",
"url": "http://weblog.rubyonrails.org/2007/11/24/ruby-on-rails-1-2-6-security-and-maintenance-release"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26598"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA07-352A.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/4009"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/4238"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "session fixation protection mechanism in cgi_process.rb in Rails"
}
GHSA-P4PR-3VWW-7G7V
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2023-02-03 18:30In cdev_get of char_dev.c, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-153467744
{
"affected": [],
"aliases": [
"CVE-2020-0305"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-17T20:15:00Z",
"severity": "MODERATE"
},
"details": "In cdev_get of char_dev.c, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-153467744",
"id": "GHSA-p4pr-3vww-7g7v",
"modified": "2023-02-03T18:30:33Z",
"published": "2022-05-24T17:23:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0305"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2020-06-01"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00009.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00047.html"
}
],
"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-P4WW-QWW8-JC5F
Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-09-11 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set.
Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption.
Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID
Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text
Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller
Changes in v4: -- split into two patches
Changes in v5: -- delete empty line between tags
Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text
Patchwork: https://patchwork.freedesktop.org/patch/516121/
{
"affected": [],
"aliases": [
"CVE-2022-48898"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer\n\nThere are 3 possible interrupt sources are handled by DP controller,\nHPDstatus, Controller state changes and Aux read/write transaction.\nAt every irq, DP controller have to check isr status of every interrupt\nsources and service the interrupt if its isr status bits shows interrupts\nare pending. There is potential race condition may happen at current aux\nisr handler implementation since it is always complete dp_aux_cmd_fifo_tx()\neven irq is not for aux read or write transaction. This may cause aux read\ntransaction return premature if host aux data read is in the middle of\nwaiting for sink to complete transferring data to host while irq happen.\nThis will cause host\u0027s receiving buffer contains unexpected data. This\npatch fixes this problem by checking aux isr and return immediately at\naux isr handler if there are no any isr status bits set.\n\nCurrent there is a bug report regrading eDP edid corruption happen during\nsystem booting up. After lengthy debugging to found that VIDEO_READY\ninterrupt was continuously firing during system booting up which cause\ndp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data\nfrom aux hardware buffer which is not yet contains complete data transfer\nfrom sink. This cause edid corruption.\n\nFollows are the signature at kernel logs when problem happen,\nEDID has corrupt header\npanel-simple-dp-aux aux-aea0000.edp: Couldn\u0027t identify panel via EDID\n\nChanges in v2:\n-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()\n-- add more commit text\n\nChanges in v3:\n-- add Stephen suggested\n-- dp_aux_isr() return IRQ_XXX back to caller\n-- dp_ctrl_isr() return IRQ_XXX back to caller\n\nChanges in v4:\n-- split into two patches\n\nChanges in v5:\n-- delete empty line between tags\n\nChanges in v6:\n-- remove extra \"that\" and fixed line more than 75 char at commit text\n\nPatchwork: https://patchwork.freedesktop.org/patch/516121/",
"id": "GHSA-p4ww-qww8-jc5f",
"modified": "2024-09-11T18:31:02Z",
"published": "2024-08-21T09:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48898"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59"
}
],
"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-P523-J8F3-523J
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct a situation where the same PID is used for running two different programs at different times, by leveraging a race condition during crafted use of posix_spawn.
{
"affected": [],
"aliases": [
"CVE-2020-25533"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-15T22:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct a situation where the same PID is used for running two different programs at different times, by leveraging a race condition during crafted use of posix_spawn.",
"id": "GHSA-p523-j8f3-523j",
"modified": "2022-05-24T17:39:16Z",
"published": "2022-05-24T17:39:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25533"
},
{
"type": "WEB",
"url": "https://wojciechregula.blog/post/learn-xpc-exploitation-part-2-say-no-to-the-pid"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-P52G-FGPM-GPX8
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Key Guard allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50378"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:39Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Key Guard allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-p52g-fgpm-gpx8",
"modified": "2026-07-14T18:32:19Z",
"published": "2026-07-14T18:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50378"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50378"
}
],
"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-P5CQ-9Q4C-RVV7
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Runtime allows an unauthorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-50452"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:49Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Runtime allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-p5cq-9q4c-rvv7",
"modified": "2026-07-14T18:32:24Z",
"published": "2026-07-14T18:32:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50452"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50452"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
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"
}
]
}
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.