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.
2907 vulnerabilities reference this CWE, most recent first.
GHSA-5M5F-J2WX-5R78
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000016189f8
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]
LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
Call Trace:
[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c9cfcc] sch_direct_xmit+0xec/0x330
[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0
[c000000000c00ad4] __dev_queue_xmit+0x394/0x730
[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]
[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c00ca4] __dev_queue_xmit+0x564/0x730
[c000000000cf97e0] neigh_hh_output+0xd0/0x180
[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0
[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0
[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0
[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0
[c000000000d2d984] tcp_retransmit_skb+0x34/0x130
[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0
[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330
[c000000000d317bc] tcp_write_timer+0x5c/0x200
[c000000000243270] call_timer_fn+0x50/0x1c0
[c000000000243704] __run_timers.part.0+0x324/0x460
[c000000000243894] run_timer_softirq+0x54/0xa0
[c000000000ea713c] __do_softirq+0x15c/0x3e0
[c000000000166258] __irq_exit_rcu+0x158/0x190
[c000000000166420] irq_exit+0x20/0x40
[c00000000002853c] timer_interrupt+0x14c/0x2b0
[c000000000009a00] decrementer_common_virt+0x210/0x220
--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid:
ibmvnic_xmit()
{
...
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, queue_num);
ind_bufp = &tx_scrq->ind_buf;
if (test_bit(0, &adapter->resetting)) {
...
}
But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing.
Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields).
We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active.
So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()
->resetting = true
->tx_queues_active = false
disable tx queues
...
->tx_queues_active = true
start tx queues
B. Tx interrupt in ibmvnic_complete_tx():
if (->tx_queues_active)
netif_wake_subqueue();
To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which:
- must also be taken in the interrupt path (ibmvnic_complete_tx())
- shared across the multiple
---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49201"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: fix race between xmit and reset\n\nThere is a race between reset and the transmit paths that can lead to\nibmvnic_xmit() accessing an scrq after it has been freed in the reset\npath. It can result in a crash like:\n\n\tKernel attempted to read user page (0) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000000\n\tFaulting instruction address: 0xc0080000016189f8\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\t...\n\tNIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]\n\tLR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\tCall Trace:\n\t[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c9cfcc] sch_direct_xmit+0xec/0x330\n\t[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0\n\t[c000000000c00ad4] __dev_queue_xmit+0x394/0x730\n\t[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]\n\t[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c00ca4] __dev_queue_xmit+0x564/0x730\n\t[c000000000cf97e0] neigh_hh_output+0xd0/0x180\n\t[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0\n\t[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0\n\t[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0\n\t[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0\n\t[c000000000d2d984] tcp_retransmit_skb+0x34/0x130\n\t[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0\n\t[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330\n\t[c000000000d317bc] tcp_write_timer+0x5c/0x200\n\t[c000000000243270] call_timer_fn+0x50/0x1c0\n\t[c000000000243704] __run_timers.part.0+0x324/0x460\n\t[c000000000243894] run_timer_softirq+0x54/0xa0\n\t[c000000000ea713c] __do_softirq+0x15c/0x3e0\n\t[c000000000166258] __irq_exit_rcu+0x158/0x190\n\t[c000000000166420] irq_exit+0x20/0x40\n\t[c00000000002853c] timer_interrupt+0x14c/0x2b0\n\t[c000000000009a00] decrementer_common_virt+0x210/0x220\n\t--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c\n\nThe immediate cause of the crash is the access of tx_scrq in the following\nsnippet during a reset, where the tx_scrq can be either NULL or an address\nthat will soon be invalid:\n\n\tibmvnic_xmit()\n\t{\n\t\t...\n\t\ttx_scrq = adapter-\u003etx_scrq[queue_num];\n\t\ttxq = netdev_get_tx_queue(netdev, queue_num);\n\t\tind_bufp = \u0026tx_scrq-\u003eind_buf;\n\n\t\tif (test_bit(0, \u0026adapter-\u003eresetting)) {\n\t\t...\n\t}\n\nBut beyond that, the call to ibmvnic_xmit() itself is not safe during a\nreset and the reset path attempts to avoid this by stopping the queue in\nibmvnic_cleanup(). However just after the queue was stopped, an in-flight\nibmvnic_complete_tx() could have restarted the queue even as the reset is\nprogressing.\n\nSince the queue was restarted we could get a call to ibmvnic_xmit() which\ncan then access the bad tx_scrq (or other fields).\n\nWe cannot however simply have ibmvnic_complete_tx() check the -\u003eresetting\nbit and skip starting the queue. This can race at the \"back-end\" of a good\nreset which just restarted the queue but has not cleared the -\u003eresetting\nbit yet. If we skip restarting the queue due to -\u003eresetting being true,\nthe queue would remain stopped indefinitely potentially leading to transmit\ntimeouts.\n\nIOW -\u003eresetting is too broad for this purpose. Instead use a new flag\nthat indicates whether or not the queues are active. Only the open/\nreset paths control when the queues are active. ibmvnic_complete_tx()\nand others wake up the queue only if the queue is marked active.\n\nSo we will have:\n\tA. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()\n\n\t\t-\u003eresetting = true\n\t\t-\u003etx_queues_active = false\n\t\tdisable tx queues\n\t\t...\n\t\t-\u003etx_queues_active = true\n\t\tstart tx queues\n\n\tB. Tx interrupt in ibmvnic_complete_tx():\n\n\t\tif (-\u003etx_queues_active)\n\t\t\tnetif_wake_subqueue();\n\nTo ensure that -\u003etx_queues_active and state of the queues are consistent,\nwe need a lock which:\n\n\t- must also be taken in the interrupt path (ibmvnic_complete_tx())\n\t- shared across the multiple\n---truncated---",
"id": "GHSA-5m5f-j2wx-5r78",
"modified": "2025-03-18T21:31:59Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49201"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bd58abf595b6cf1ba6dd47ec887c4c009155fc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4219196d1f662cb10a462eb9e076633a3fc31a15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/475f9cce98b63bc145b4efa66fa51175d4cb345f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8507c6ade73cdbbbda5c3d31d67f52f2e1cf03fe"
}
],
"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-5M7X-C2V2-7479
Vulnerability from github – Published: 2022-05-17 00:56 – Updated: 2022-05-17 00:56Race condition in Google Chrome before 25.0.1364.152 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to the handling of media threads.
{
"affected": [],
"aliases": [
"CVE-2013-0907"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-03-05T21:55:00Z",
"severity": "HIGH"
},
"details": "Race condition in Google Chrome before 25.0.1364.152 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to the handling of media threads.",
"id": "GHSA-5m7x-c2v2-7479",
"modified": "2022-05-17T00:56:48Z",
"published": "2022-05-17T00:56:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-0907"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=174150"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16633"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2013/03/stable-channel-update_4.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5MCX-8CMV-FVGX
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 15:33In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: fix damos_walk() vs kdamond_fn() exit race
When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request.
The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks.
For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damos_walk() caller thread infinitely waits.
Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() reads the obsolete field under the lock and avoids adding a new request.
After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together.
The issue is found by sashiko [1].
{
"affected": [],
"aliases": [
"CVE-2026-46008"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: fix damos_walk() vs kdamond_fn() exit race\n\nWhen kdamond_fn() main loop is finished, the function cancels remaining\ndamos_walk() request and unset the damon_ctx-\u003ekdamond so that API callers\nand API functions themselves can show the context is terminated. \ndamos_walk() adds the caller\u0027s request to the queue first. After that, it\nshows if the kdamond of the damon_ctx is still running (damon_ctx-\u003ekdamond\nis set). Only if the kdamond is running, damos_walk() starts waiting for\nthe kdamond\u0027s handling of the newly added request.\n\nThe damos_walk() requests registration and damon_ctx-\u003ekdamond unset are\nprotected by different mutexes, though. Hence, damos_walk() could race\nwith damon_ctx-\u003ekdamond unset, and result in deadlocks.\n\nFor example, let\u0027s suppose kdamond successfully finished the damow_walk()\nrequest cancelling. Right after that, damos_walk() is called for the\ncontext. It registers the new request, and shows the context is still\nrunning, because damon_ctx-\u003ekdamond unset is not yet done. Hence the\ndamos_walk() caller starts waiting for the handling of the request. \nHowever, the kdamond is already on the termination steps, so it never\nhandles the new request. As a result, the damos_walk() caller thread\ninfinitely waits.\n\nFix this by introducing another damon_ctx field, namely\nwalk_control_obsolete. It is protected by the\ndamon_ctx-\u003ewalk_control_lock, which protects damos_walk() request\nregistration. Initialize (unset) it in kdamond_fn() before letting\ndamon_start() returns and set it just before the cancelling of the\nremaining damos_walk() request is executed. damos_walk() reads the\nobsolete field under the lock and avoids adding a new request.\n\nAfter this change, only requests that are guaranteed to be handled or\ncancelled are registered. Hence the after-registration DAMON context\ntermination check is no longer needed. Remove it together.\n\nThe issue is found by sashiko [1].",
"id": "GHSA-5mcx-8cmv-fvgx",
"modified": "2026-06-16T15:33:40Z",
"published": "2026-05-27T15:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ba956a239ba6e3fae8555d3660e22e675be63b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33c3f6c2b48cd84b441dba1ee3e62290e53930f4"
}
],
"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-5MG6-XP8P-MRRM
Vulnerability from github – Published: 2023-04-27 21:30 – Updated: 2024-04-04 03:42Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-21712"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-27T19:15:13Z",
"severity": "HIGH"
},
"details": "Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability",
"id": "GHSA-5mg6-xp8p-mrrm",
"modified": "2024-04-04T03:42:52Z",
"published": "2023-04-27T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21712"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21712"
}
],
"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-5MGM-HH8W-J47P
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-03-24 00:00Product: AndroidVersions: Android kernelAndroid ID: A-173788806References: Upstream kernel
{
"affected": [],
"aliases": [
"CVE-2021-39713"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-16T15:15:00Z",
"severity": "CRITICAL"
},
"details": "Product: AndroidVersions: Android kernelAndroid ID: A-173788806References: Upstream kernel",
"id": "GHSA-5mgm-hh8w-j47p",
"modified": "2022-03-24T00:00:37Z",
"published": "2022-03-17T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39713"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-03-01"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html"
}
],
"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-5MJF-6GR5-JVH8
Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30A Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in the Flow-processing Daemon (flowd) of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (Dos).
On SRX Series devices when two different threads try to simultaneously process a queue which is used for TCP events flowd will crash. One of these threads can not be triggered externally, so the exploitation of this race condition is outside the attackers direct control.
Continued exploitation of this issue will lead to a sustained DoS.
This issue affects Juniper Networks Junos OS:
- 21.2 versions earlier than 21.2R3-S5;
- 21.3 versions earlier than 21.3R3-S5;
- 21.4 versions earlier than 21.4R3-S4;
- 22.1 versions earlier than 22.1R3-S3;
- 22.2 versions earlier than 22.2R3-S1;
- 22.3 versions earlier than 22.3R2-S2, 22.3R3;
- 22.4 versions earlier than 22.4R2-S1, 22.4R3.
This issue does not affect Juniper Networks Junos OS versions earlier than 21.2R1.
{
"affected": [],
"aliases": [
"CVE-2024-21601"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-12T01:15:48Z",
"severity": "MODERATE"
},
"details": "\nA Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027) vulnerability in the Flow-processing Daemon (flowd) of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (Dos).\n\nOn SRX Series devices when two different threads try to simultaneously process a queue which is used for TCP events flowd will crash. One of these threads can not be triggered externally, so the exploitation of this race condition is outside the attackers direct control.\n\nContinued exploitation of this issue will lead to a sustained DoS.\n\nThis issue affects Juniper Networks Junos OS:\n\n\n\n * 21.2 versions earlier than 21.2R3-S5;\n * 21.3 versions earlier than 21.3R3-S5;\n * 21.4 versions earlier than 21.4R3-S4;\n * 22.1 versions earlier than 22.1R3-S3;\n * 22.2 versions earlier than 22.2R3-S1;\n * 22.3 versions earlier than 22.3R2-S2, 22.3R3;\n * 22.4 versions earlier than 22.4R2-S1, 22.4R3.\n\n\n\n\nThis issue does not affect Juniper Networks Junos OS versions earlier than 21.2R1.\n\n\n\n",
"id": "GHSA-5mjf-6gr5-jvh8",
"modified": "2024-01-12T03:30:48Z",
"published": "2024-01-12T03:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21601"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA75742"
},
{
"type": "WEB",
"url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5P5J-VWV3-3HM9
Vulnerability from github – Published: 2023-02-27 21:30 – Updated: 2023-03-07 21:30A race condition was addressed with improved state handling. This issue is fixed in tvOS 15.6, watchOS 8.7, iOS 15.6 and iPadOS 15.6. An app with arbitrary kernel read and write capability may be able to bypass Pointer Authentication.
{
"affected": [],
"aliases": [
"CVE-2022-32844"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-27T20:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition was addressed with improved state handling. This issue is fixed in tvOS 15.6, watchOS 8.7, iOS 15.6 and iPadOS 15.6. An app with arbitrary kernel read and write capability may be able to bypass Pointer Authentication.",
"id": "GHSA-5p5j-vwv3-3hm9",
"modified": "2023-03-07T21:30:17Z",
"published": "2023-02-27T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32844"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213340"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213342"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213346"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5PC9-JC94-9295
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.
{
"affected": [],
"aliases": [
"CVE-2013-1256"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-02-13T12:04:00Z",
"severity": "MODERATE"
},
"details": "Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.",
"id": "GHSA-5pc9-jc94-9295",
"modified": "2022-05-13T01:15:44Z",
"published": "2022-05-13T01:15:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1256"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16436"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA13-043B.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5PQW-JJJW-GF67
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-49120"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-453"
],
"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-5pqw-jjjw-gf67",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49120"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49120"
}
],
"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-5PQX-P8MP-CXRF
Vulnerability from github – Published: 2026-03-24 21:31 – Updated: 2026-03-24 21:31NVIDIA Triton Inference Server Sagemaker HTTP server contains a vulnerability where an attacker may cause an exception. A successful exploit of this vulnerability may lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-33238"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T21:16:24Z",
"severity": "HIGH"
},
"details": "NVIDIA Triton Inference Server Sagemaker HTTP server contains a vulnerability where an attacker may cause an exception. A successful exploit of this vulnerability may lead to denial of service.",
"id": "GHSA-5pqx-p8mp-cxrf",
"modified": "2026-03-24T21:31:24Z",
"published": "2026-03-24T21:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33238"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5790"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33238"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.