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.
2903 vulnerabilities reference this CWE, most recent first.
GHSA-58F5-8JQ5-R8P2
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2025-11-04 00:32A race condition was addressed with improved locking. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to leak sensitive kernel state.
{
"affected": [],
"aliases": [
"CVE-2024-54510"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:15:31Z",
"severity": "MODERATE"
},
"details": "A race condition was addressed with improved locking. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to leak sensitive kernel state.",
"id": "GHSA-58f5-8jq5-r8p2",
"modified": "2025-11-04T00:32:14Z",
"published": "2024-12-12T03:33:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54510"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121837"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121838"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121839"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121840"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121842"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121843"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121844"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/11"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/5"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/6"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/7"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-58HM-MCRJ-H6XH
Vulnerability from github – Published: 2022-05-17 05:42 – Updated: 2022-05-17 05:42Race condition in the Kernel::System::Main::FileWrite method in Open Ticket Request System (OTRS) before 2.4.8 allows remote authenticated users to corrupt the TicketCounter.log data in opportunistic circumstances by creating tickets.
{
"affected": [],
"aliases": [
"CVE-2010-4765"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-03-18T16:55:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the Kernel::System::Main::FileWrite method in Open Ticket Request System (OTRS) before 2.4.8 allows remote authenticated users to corrupt the TicketCounter.log data in opportunistic circumstances by creating tickets.",
"id": "GHSA-58hm-mcrj-h6xh",
"modified": "2022-05-17T05:42:51Z",
"published": "2022-05-17T05:42:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4765"
},
{
"type": "WEB",
"url": "http://bugs.otrs.org/show_bug.cgi?id=4936"
},
{
"type": "WEB",
"url": "http://source.otrs.org/viewvc.cgi/otrs/CHANGES?revision=1.1807"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-58JM-PCR7-QMP6
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In installKey of KeyUtil.cpp, there is a possible failure of file encryption due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-140762419
{
"affected": [],
"aliases": [
"CVE-2023-21178"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:14Z",
"severity": "MODERATE"
},
"details": "In installKey of KeyUtil.cpp, there is a possible failure of file encryption due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-140762419",
"id": "GHSA-58jm-pcr7-qmp6",
"modified": "2024-04-04T05:15:10Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21178"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-58M7-HFR6-RRX2
Vulnerability from github – Published: 2024-10-23 06:31 – Updated: 2025-03-07 18:31In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix move_normal_pmd/retract_page_tables race
In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved.
At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination.
The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap:
process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks
When this happens, move_normal_pmd() can end up creating bogus PMD entries
in the line pmd_populate(mm, new_pmd, pmd_pgtable(pmd)). The effect
depends on arch-specific and machine-specific details; on x86, you can end
up with physical page 0 mapped as a page table, which is likely
exploitable for user->kernel privilege escalation.
Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check.
Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that.
Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.
{
"affected": [],
"aliases": [
"CVE-2024-50066"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-23T06:15:10Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix move_normal_pmd/retract_page_tables race\n\nIn mremap(), move_page_tables() looks at the type of the PMD entry and the\nspecified address range to figure out by which method the next chunk of\npage table entries should be moved.\n\nAt that point, the mmap_lock is held in write mode, but no rmap locks are\nheld yet. For PMD entries that point to page tables and are fully covered\nby the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,\nwhich first takes rmap locks, then does move_normal_pmd(). \nmove_normal_pmd() takes the necessary page table locks at source and\ndestination, then moves an entire page table from the source to the\ndestination.\n\nThe problem is: The rmap locks, which protect against concurrent page\ntable removal by retract_page_tables() in the THP code, are only taken\nafter the PMD entry has been read and it has been decided how to move it. \nSo we can race as follows (with two processes that have mappings of the\nsame tmpfs file that is stored on a tmpfs mount with huge=advise); note\nthat process A accesses page tables through the MM while process B does it\nthrough the file rmap:\n\nprocess A process B\n========= =========\nmremap\n mremap_to\n move_vma\n move_page_tables\n get_old_pmd\n alloc_new_pmd\n *** PREEMPT ***\n madvise(MADV_COLLAPSE)\n do_madvise\n madvise_walk_vmas\n madvise_vma_behavior\n madvise_collapse\n hpage_collapse_scan_file\n collapse_file\n retract_page_tables\n i_mmap_lock_read(mapping)\n pmdp_collapse_flush\n i_mmap_unlock_read(mapping)\n move_pgt_entry(NORMAL_PMD, ...)\n take_rmap_locks\n move_normal_pmd\n drop_rmap_locks\n\nWhen this happens, move_normal_pmd() can end up creating bogus PMD entries\nin the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect\ndepends on arch-specific and machine-specific details; on x86, you can end\nup with physical page 0 mapped as a page table, which is likely\nexploitable for user-\u003ekernel privilege escalation.\n\nFix the race by letting process B recheck that the PMD still points to a\npage table after the rmap locks have been taken. Otherwise, we bail and\nlet the caller fall back to the PTE-level copying path, which will then\nbail immediately at the pmd_none() check.\n\nBug reachability: Reaching this bug requires that you can create\nshmem/file THP mappings - anonymous THP uses different code that doesn\u0027t\nzap stuff under rmap locks. File THP is gated on an experimental config\nflag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need\nshmem THP to hit this bug. As far as I know, getting shmem THP normally\nrequires that you can mount your own tmpfs with the right mount flags,\nwhich would require creating your own user+mount namespace; though I don\u0027t\nknow if some distros maybe enable shmem THP by default or something like\nthat.\n\nBug impact: This issue can likely be used for user-\u003ekernel privilege\nescalation when it is reachable.",
"id": "GHSA-58m7-hfr6-rrx2",
"modified": "2025-03-07T18:31:00Z",
"published": "2024-10-23T06:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50066"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1552ce9ce8af47c0fe911682e5e1855e25851ca9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17396e32f975130b3e6251f024c8807d192e4c3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa"
},
{
"type": "WEB",
"url": "https://project-zero.issues.chromium.org/issues/371047675"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2024-50066-kernel-detection-vulnerability"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2024-50066-kernel-mitigation-vulnerability"
}
],
"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-58QX-PWX2-GQM9
Vulnerability from github – Published: 2024-12-02 15:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
mptcp: error out earlier on disconnect
Eric reported a division by zero splat in the MPTCP protocol:
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef
and provided a nice reproducer.
The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss.
Catch the error and return without performing any additional operations on the current socket.
{
"affected": [],
"aliases": [
"CVE-2024-53123"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-02T14:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: error out earlier on disconnect\n\nEric reported a division by zero splat in the MPTCP protocol:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted\n6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0\nHardware name: Google Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nRIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163\nCode: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8\n0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 \u003cf7\u003e 7c\n24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89\nRSP: 0018:ffffc900041f7930 EFLAGS: 00010293\nRAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b\nRDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004\nRBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67\nR10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80\nR13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000\nFS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u003cTASK\u003e\n__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493\nmptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]\nmptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289\ninet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885\nsock_recvmsg_nosec net/socket.c:1051 [inline]\nsock_recvmsg+0x1b2/0x250 net/socket.c:1073\n__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265\n__do_sys_recvfrom net/socket.c:2283 [inline]\n__se_sys_recvfrom net/socket.c:2279 [inline]\n__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7feb5d857559\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u003c48\u003e 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559\nRDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000\nR10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c\nR13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef\n\nand provided a nice reproducer.\n\nThe root cause is the current bad handling of racing disconnect.\nAfter the blamed commit below, sk_wait_data() can return (with\nerror) with the underlying socket disconnected and a zero rcv_mss.\n\nCatch the error and return without performing any additional\noperations on the current socket.",
"id": "GHSA-58qx-pwx2-gqm9",
"modified": "2025-11-04T00:32:09Z",
"published": "2024-12-02T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53123"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/581302298524e9d77c4c44ff5156a6cd112227ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/955388e1d5d222c4101c596b536d41b91a8b212e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a66805c9b22caf4e42af7a616f6c6b83c90d1010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a749b23059b43a9b1787eb36c5d9d44150a34238"
},
{
"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:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-58R5-75PR-V3G7
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-12 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-34331"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T18:17:06Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-58r5-75pr-v3g7",
"modified": "2026-05-12T18:30:42Z",
"published": "2026-05-12T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34331"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-34331"
}
],
"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-5969-X38P-XRJJ
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-16 00:00Windows DNS Server Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-24536, CVE-2022-26811, CVE-2022-26812, CVE-2022-26813, CVE-2022-26814, CVE-2022-26815, CVE-2022-26817, CVE-2022-26818, CVE-2022-26820, CVE-2022-26821, CVE-2022-26822, CVE-2022-26823, CVE-2022-26824, CVE-2022-26825, CVE-2022-26826, CVE-2022-26829.
{
"affected": [],
"aliases": [
"CVE-2022-26819"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T19:15:00Z",
"severity": "MODERATE"
},
"details": "Windows DNS Server Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-24536, CVE-2022-26811, CVE-2022-26812, CVE-2022-26813, CVE-2022-26814, CVE-2022-26815, CVE-2022-26817, CVE-2022-26818, CVE-2022-26820, CVE-2022-26821, CVE-2022-26822, CVE-2022-26823, CVE-2022-26824, CVE-2022-26825, CVE-2022-26826, CVE-2022-26829.",
"id": "GHSA-5969-x38p-xrjj",
"modified": "2022-04-16T00:00:31Z",
"published": "2022-04-16T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26819"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26819"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26819"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5975-JWQ3-JMM6
Vulnerability from github – Published: 2022-05-14 02:09 – Updated: 2022-05-14 02:09Race condition in the ResourceDispatcherHostImpl::BeginRequest function in content/browser/loader/resource_dispatcher_host_impl.cc in Google Chrome before 50.0.2661.102 allows remote attackers to make arbitrary HTTP requests by leveraging access to a renderer process and reusing a request ID.
{
"affected": [],
"aliases": [
"CVE-2016-1670"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-05-14T21:59:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the ResourceDispatcherHostImpl::BeginRequest function in content/browser/loader/resource_dispatcher_host_impl.cc in Google Chrome before 50.0.2661.102 allows remote attackers to make arbitrary HTTP requests by leveraging access to a renderer process and reusing a request ID.",
"id": "GHSA-5975-jwq3-jmm6",
"modified": "2022-05-14T02:09:50Z",
"published": "2022-05-14T02:09:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1670"
},
{
"type": "WEB",
"url": "https://codereview.chromium.org/1608573002"
},
{
"type": "WEB",
"url": "https://crbug.com/578882"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201605-02"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2016/05/stable-channel-update.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-05/msg00043.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-05/msg00050.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-06/msg00048.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-1080.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3590"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/90584"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1035872"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2960-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-597G-3PHW-6986
Vulnerability from github – Published: 2026-01-13 18:45 – Updated: 2026-01-13 18:45Impact
TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in virtualenv allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv's app_data and lock file operations to attacker-controlled locations.
Affected versions: All versions up to and including 20.36.1
Affected users: Any user running virtualenv on multi-user systems where untrusted local users have filesystem access to shared temporary directories or where VIRTUALENV_OVERRIDE_APP_DATA points to a user-writable location.
Attack scenarios: - Cache poisoning: Attacker corrupts wheels or Python metadata in the cache - Information disclosure: Attacker reads sensitive cached data or metadata - Lock bypass: Attacker controls lock file semantics to cause concurrent access violations - Denial of service: Lock starvation preventing virtualenv operations
Patches
The vulnerability has been patched by replacing check-then-act patterns with atomic os.makedirs(..., exist_ok=True) operations.
Fixed in: PR #3013
Versions with the fix: 20.36.2 and later
Users should upgrade to version 20.36.2 or later.
Workarounds
If you cannot upgrade immediately:
- Ensure
VIRTUALENV_OVERRIDE_APP_DATApoints to a directory owned by the current user with restricted permissions (mode 0700) - Avoid running
virtualenvin shared temporary directories where other users have write access - Use separate user accounts for different projects to isolate app_data directories
References
- GitHub PR: https://github.com/pypa/virtualenv/pull/3013
- Vulnerability reported by: @tsigouris007
- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (TOCTOU)
- CWE-59: Improper Link Resolution Before File Access
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "virtualenv"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "20.36.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22702"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T18:45:57Z",
"nvd_published_at": "2026-01-10T07:16:02Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nTOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in `virtualenv` allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv\u0027s app_data and lock file operations to attacker-controlled locations.\n\n**Affected versions:** All versions up to and including 20.36.1\n\n**Affected users:** Any user running `virtualenv` on multi-user systems where untrusted local users have filesystem access to shared temporary directories or where `VIRTUALENV_OVERRIDE_APP_DATA` points to a user-writable location.\n\n**Attack scenarios:**\n- Cache poisoning: Attacker corrupts wheels or Python metadata in the cache\n- Information disclosure: Attacker reads sensitive cached data or metadata\n- Lock bypass: Attacker controls lock file semantics to cause concurrent access violations\n- Denial of service: Lock starvation preventing virtualenv operations\n\n## Patches\n\nThe vulnerability has been patched by replacing check-then-act patterns with atomic `os.makedirs(..., exist_ok=True)` operations.\n\n**Fixed in:** PR #3013\n\n**Versions with the fix:** 20.36.2 and later\n\nUsers should upgrade to version 20.36.2 or later.\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n1. Ensure `VIRTUALENV_OVERRIDE_APP_DATA` points to a directory owned by the current user with restricted permissions (mode 0700)\n2. Avoid running `virtualenv` in shared temporary directories where other users have write access\n3. Use separate user accounts for different projects to isolate app_data directories\n\n## References\n\n- GitHub PR: https://github.com/pypa/virtualenv/pull/3013\n- Vulnerability reported by: @tsigouris007\n- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (TOCTOU)\n- CWE-59: Improper Link Resolution Before File Access",
"id": "GHSA-597g-3phw-6986",
"modified": "2026-01-13T18:45:57Z",
"published": "2026-01-13T18:45:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/security/advisories/GHSA-597g-3phw-6986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22702"
},
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/pull/3013"
},
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/commit/dec4cec5d16edaf83a00a658f32d1e032661cebc"
},
{
"type": "PACKAGE",
"url": "https://github.com/pypa/virtualenv"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "virtualenv Has TOCTOU Vulnerabilities in Directory Creation"
}
GHSA-598C-CC55-MWV5
Vulnerability from github – Published: 2024-08-16 00:32 – Updated: 2024-08-16 18:30In multiple functions of TranscodingResourcePolicy.cpp, there is a possible memory corruption 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-2024-34731"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-368"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-15T22:15:06Z",
"severity": "HIGH"
},
"details": "In multiple functions of TranscodingResourcePolicy.cpp, there is a possible memory corruption 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-598c-cc55-mwv5",
"modified": "2024-08-16T18:30:57Z",
"published": "2024-08-16T00:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34731"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/av/+/4b68b00993849b6a7f0e6d075bc2c8bb2e184e61"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/hardware/interfaces/+/0ff19d1f89614fce9454fb415bcbfcbcf3caf76e"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/hardware/interfaces/+/d63d09261806f7f1aa01406867f2a9e169356fca"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/system/nfc/+/1037992b9abcde1e3560bd895f62644a68563b3d"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/system/security/+/d3805312d73433e34ef69a645b553a2969c5dc93"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2024-08-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/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.