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.
3563 vulnerabilities reference this CWE, most recent first.
GHSA-2QCJ-HQQ8-V6F6
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-05 15:31In the Linux kernel, the following vulnerability has been resolved:
mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()
The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below:
core 0 core 1 swapoff
del_from_avail_list(si) waiting
try lock si->lock acquire swap_avail_lock and re-add si into swap_avail_head
acquire si->lock but missing si already being added again, and continuing to clear SWP_WRITEOK, etc.
It can be easily found that a massive warning messages can be triggered inside get_swap_pages() by some special cases, for example, we call madvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile, run much swapon-swapoff operations (e.g. stress-ng-swap).
However, in the worst case, panic can be caused by the above scene. In swapoff(), the memory used by si could be kept in swap_info[] after turning off a swap. This means memory corruption will not be caused immediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)
------------[ cut here ]------------ top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70 Modules linked in: rfkill(E) crct10dif_ce(E)... CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+ Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : plist_check_prev_next_node+0x50/0x70 lr : plist_check_prev_next_node+0x50/0x70 sp : ffff0018009d3c30 x29: ffff0018009d3c40 x28: ffff800011b32a98 x27: 0000000000000000 x26: ffff001803908000 x25: ffff8000128ea088 x24: ffff800011b32a48 x23: 0000000000000028 x22: ffff001800875c00 x21: ffff800010f9e520 x20: ffff001800875c00 x19: ffff001800fdc6e0 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: 0736076307640766 x14: 0730073007380731 x13: 0736076307640766 x12: 0730073007380731 x11: 000000000004058d x10: 0000000085a85b76 x9 : ffff8000101436e4 x8 : ffff800011c8ce08 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff0017df9ed338 x4 : 0000000000000001 x3 : ffff8017ce62a000 x2 : ffff0017df9ed340 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 irq event stamp: 2082270
Now, si->lock locked before calling 'del_from_avail_list()' to make sure other thread see the si had been deleted and SWP_WRITEOK cleared together, will not reinsert again.
This problem exists in versions after stable 5.10.y.
{
"affected": [],
"aliases": [
"CVE-2023-53623"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swap: fix swap_info_struct race between swapoff and get_swap_pages()\n\nThe si-\u003elock must be held when deleting the si from the available list. \nOtherwise, another thread can re-add the si to the available list, which\ncan lead to memory corruption. The only place we have found where this\nhappens is in the swapoff path. This case can be described as below:\n\ncore 0 core 1\nswapoff\n\ndel_from_avail_list(si) waiting\n\ntry lock si-\u003elock acquire swap_avail_lock\n and re-add si into\n swap_avail_head\n\nacquire si-\u003elock but missing si already being added again, and continuing\nto clear SWP_WRITEOK, etc.\n\nIt can be easily found that a massive warning messages can be triggered\ninside get_swap_pages() by some special cases, for example, we call\nmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,\nrun much swapon-swapoff operations (e.g. stress-ng-swap).\n\nHowever, in the worst case, panic can be caused by the above scene. In\nswapoff(), the memory used by si could be kept in swap_info[] after\nturning off a swap. This means memory corruption will not be caused\nimmediately until allocated and reset for a new swap in the swapon path. \nA panic message caused: (with CONFIG_PLIST_DEBUG enabled)\n\n------------[ cut here ]------------\ntop: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a\nprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d\nnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a\nWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70\nModules linked in: rfkill(E) crct10dif_ce(E)...\nCPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+\nHardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015\npstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)\npc : plist_check_prev_next_node+0x50/0x70\nlr : plist_check_prev_next_node+0x50/0x70\nsp : ffff0018009d3c30\nx29: ffff0018009d3c40 x28: ffff800011b32a98\nx27: 0000000000000000 x26: ffff001803908000\nx25: ffff8000128ea088 x24: ffff800011b32a48\nx23: 0000000000000028 x22: ffff001800875c00\nx21: ffff800010f9e520 x20: ffff001800875c00\nx19: ffff001800fdc6e0 x18: 0000000000000030\nx17: 0000000000000000 x16: 0000000000000000\nx15: 0736076307640766 x14: 0730073007380731\nx13: 0736076307640766 x12: 0730073007380731\nx11: 000000000004058d x10: 0000000085a85b76\nx9 : ffff8000101436e4 x8 : ffff800011c8ce08\nx7 : 0000000000000000 x6 : 0000000000000001\nx5 : ffff0017df9ed338 x4 : 0000000000000001\nx3 : ffff8017ce62a000 x2 : ffff0017df9ed340\nx1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n plist_check_prev_next_node+0x50/0x70\n plist_check_head+0x80/0xf0\n plist_add+0x28/0x140\n add_to_avail_list+0x9c/0xf0\n _enable_swap_info+0x78/0xb4\n __do_sys_swapon+0x918/0xa10\n __arm64_sys_swapon+0x20/0x30\n el0_svc_common+0x8c/0x220\n do_el0_svc+0x2c/0x90\n el0_svc+0x1c/0x30\n el0_sync_handler+0xa8/0xb0\n el0_sync+0x148/0x180\nirq event stamp: 2082270\n\nNow, si-\u003elock locked before calling \u0027del_from_avail_list()\u0027 to make sure\nother thread see the si had been deleted and SWP_WRITEOK cleared together,\nwill not reinsert again.\n\nThis problem exists in versions after stable 5.10.y.",
"id": "GHSA-2qcj-hqq8-v6f6",
"modified": "2026-02-05T15:31:08Z",
"published": "2025-10-07T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53623"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/111a79d9b92f0a679fe300ccd3119ae9741f3d54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bdf1514b4268d29360ba9e43becdd49955bc7ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fe7d6b992113719e96744d974212df3fcddc76c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85cc118ce6f1a627901b6db50c9d01f2ad78cdbf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a55f268abdb74ac5633b75a09fefb58458e9d2a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9927d3a60ca9ed35625470888629c074e687ba0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7bba7ddb4318d5ea939c8db747c2c2780ab66f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea8c42b3b6d95ced3a4f555f04686d00ef0bb206"
}
],
"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-2QHP-87PG-JH75
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-14 00:31In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()
need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware.
iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario:
CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!)
CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help.
Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.
{
"affected": [],
"aliases": [
"CVE-2026-68329"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:20:23Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Wait for completion instead of returning early in iommu_completion_wait()\n\nneed_sync is a per-IOMMU flag shared by all domains and devices behind\nthat IOMMU. It is set whenever a command is queued with sync == true and\ncleared when a completion-wait (CWAIT) command is queued. However, a\ncleared need_sync only means that a covering CWAIT has been queued, not\nthat all previously queued commands have actually completed in hardware.\n\niommu_completion_wait() read need_sync locklessly and returned early\nwhen it was false. This breaks the \"block until all previously queued\ncommands have completed\" contract in a multi-CPU scenario:\n\n CPU2: queue inv-B =\u003e need_sync = true\n CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N)\n CPU2: read need_sync == false =\u003e return 0 (no wait!)\n\nCPU2 returns without waiting for any sequence number even though its\ninv-B may not have completed yet (CWAIT(N), queued after inv-B, has not\nbeen signaled). CPU2 then proceeds to, for example, free page-table\npages while the IOMMU can still walk stale translations, opening a\nuse-after-free window. This is a logical race in the meaning of the\nflag, not a memory-visibility issue, so barriers alone do not help.\n\nFix it without losing the optimization of avoiding redundant CWAIT\ncommands: take iommu-\u003elock before testing need_sync, and when it is\nfalse do not return early but wait for the last allocated sequence\nnumber (cmd_sem_val). Since need_sync == false implies no sync command\nwas queued after the last CWAIT, that CWAIT is FIFO-ordered after every\nnot-yet-completed command, so waiting for its sequence number guarantees\nall prior commands (possibly queued by another CPU) have completed. The\ncommon path with pending work is unchanged and no extra hardware command\nis issued.",
"id": "GHSA-2qhp-87pg-jh75",
"modified": "2026-08-14T00:31:55Z",
"published": "2026-08-10T15:33:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68329"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02f8cefa2ad95ea3754f0cfd6fbae7f866202ccb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e75a8255f11c81fb07e81e5029cfd75804350a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93494bd446396c257fb589f59894577e96e406e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab7faf5a172ebfdc423ebb3eea4d472740de82f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d053eb7e09e10cbdca3fca8b35c1017d438091b2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2QPH-M57G-Q5R9
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_recovery.
While reading sysctl_tcp_recovery, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
{
"affected": [],
"aliases": [
"CVE-2022-49574"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_recovery.\n\nWhile reading sysctl_tcp_recovery, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.",
"id": "GHSA-2qph-m57g-q5r9",
"modified": "2025-03-10T21:31:10Z",
"published": "2025-03-10T21:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49574"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52ee7f5c4811ce6be1becd14d38ba1f8a8a0df81"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92c35113c63306091df9211375eebd0abd8c2160"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a31e2d0cb5cfa2aae3144cac04f25031d5d20fb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7a492db1f7c37c758a66915908677bd8bc5d368"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8781f7cd04091744f474a2bada74772084b9dc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7d2ef837e14a971a05f60ea08c47f3fed1a36e4"
}
],
"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-2QVJ-3GVP-R69W
Vulnerability from github – Published: 2022-05-17 04:54 – Updated: 2025-04-11 04:16Multiple race conditions in ipc/shm.c in the Linux kernel before 3.12.2 allow local users to cause a denial of service (use-after-free and system crash) or possibly have unspecified other impact via a crafted application that uses shmctl IPC_RMID operations in conjunction with other shm system calls.
{
"affected": [],
"aliases": [
"CVE-2013-7026"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-12-09T18:55:00Z",
"severity": "MODERATE"
},
"details": "Multiple race conditions in ipc/shm.c in the Linux kernel before 3.12.2 allow local users to cause a denial of service (use-after-free and system crash) or possibly have unspecified other impact via a crafted application that uses shmctl IPC_RMID operations in conjunction with other shm system calls.",
"id": "GHSA-2qvj-3gvp-r69w",
"modified": "2025-04-11T04:16:53Z",
"published": "2022-05-17T04:54:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-7026"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.12.2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2070-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2075-1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2QWP-9C8H-MRVC
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync
hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently.
Take hdev lock to prevent hci_conn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration.
{
"affected": [],
"aliases": [
"CVE-2026-43019"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: fix potential UAF in set_cig_params_sync\n\nhci_conn lookup and field access must be covered by hdev lock in\nset_cig_params_sync, otherwise it\u0027s possible it is freed concurrently.\n\nTake hdev lock to prevent hci_conn from being deleted or modified\nconcurrently. Just RCU lock is not suitable here, as we also want to\navoid \"tearing\" in the configuration.",
"id": "GHSA-2qwp-9c8h-mrvc",
"modified": "2026-06-19T15:33:09Z",
"published": "2026-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43019"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66d432e9b45bae7881ffcdb12cd8fd0bf254ef02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7502c1cf303b69f71d085f5ff7251b0e1b0f09df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d568fede8eac91161a60b710aa920abe9b0fb9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2639a7f0f5bf7d73f337f8f077c19415c62ed2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bad65b4b0a96139f023eadc28a33125963208449"
}
],
"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-2R59-6PXX-3WQV
Vulnerability from github – Published: 2022-05-13 01:25 – Updated: 2022-05-13 01:25procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.
{
"affected": [],
"aliases": [
"CVE-2018-1121"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-13T20:29:00Z",
"severity": "MODERATE"
},
"details": "procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel\u0027s proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng\u0027s utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.",
"id": "GHSA-2r59-6pxx-3wqv",
"modified": "2022-05-13T01:25:29Z",
"published": "2022-05-13T01:25:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1121"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1121"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44806"
},
{
"type": "WEB",
"url": "https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2018/q2/122"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104214"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2R6Q-6C8C-G762
Vulnerability from github – Published: 2021-08-25 20:58 – Updated: 2021-08-18 20:21An issue was discovered in the toolshed crate through 2020-11-15 for Rust. In CopyCell, the Send trait lacks bounds on the contained type.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "toolshed"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36456"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-77"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-18T20:20:49Z",
"nvd_published_at": "2021-08-08T06:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the toolshed crate through 2020-11-15 for Rust. In CopyCell\u003cT\u003e, the Send trait lacks bounds on the contained type.",
"id": "GHSA-2r6q-6c8c-g762",
"modified": "2021-08-18T20:21:02Z",
"published": "2021-08-25T20:58:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36456"
},
{
"type": "WEB",
"url": "https://github.com/ratel-rust/toolshed/issues/12"
},
{
"type": "PACKAGE",
"url": "https://github.com/ratel-rust/toolshed"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0136.html"
}
],
"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"
}
],
"summary": "Data races in toolshed"
}
GHSA-2RCH-RH42-GWQ8
Vulnerability from github – Published: 2026-09-08 18:32 – Updated: 2026-09-08 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in DNS Server allows an unauthorized attacker to execute code over a network.
{
"affected": [],
"aliases": [
"CVE-2026-69782"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T18:19:49Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in DNS Server allows an unauthorized attacker to execute code over a network.",
"id": "GHSA-2rch-rh42-gwq8",
"modified": "2026-09-08T18:32:59Z",
"published": "2026-09-08T18:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69782"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69782"
}
],
"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-2RCQ-Q564-PPC9
Vulnerability from github – Published: 2022-05-17 01:58 – Updated: 2022-05-17 01:58In all Qualcomm products with Android releases from CAF using the Linux kernel, a race condition exists in a video driver potentially leading to a use-after-free condition.
{
"affected": [],
"aliases": [
"CVE-2017-8266"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-18T18:29:00Z",
"severity": "HIGH"
},
"details": "In all Qualcomm products with Android releases from CAF using the Linux kernel, a race condition exists in a video driver potentially leading to a use-after-free condition.",
"id": "GHSA-2rcq-q564-ppc9",
"modified": "2022-05-17T01:58:39Z",
"published": "2022-05-17T01:58:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8266"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-07-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99465"
}
],
"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"
}
]
}
GHSA-2RG8-47CF-HP2J
Vulnerability from github – Published: 2026-10-09 12:31 – Updated: 2026-10-15 18:31In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another's result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate while legitimate requests were being processed, and it could be accepted as trusted without ever reaching the STS. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-97791"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-09T11:17:03Z",
"severity": "HIGH"
},
"details": "In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another\u0027s result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate while legitimate requests were being processed, and it could be accepted as trusted without ever reaching the STS. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected.\u00a0\nUsers are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.",
"id": "GHSA-2rg8-47cf-hp2j",
"modified": "2026-10-15T18:31:45Z",
"published": "2026-10-09T12:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97791"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ssdr417qgms9fjl0m8802xd8170wnk1l"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/10/09/10"
}
],
"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.