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.
2921 vulnerabilities reference this CWE, most recent first.
GHSA-HR72-3P79-RCHW
Vulnerability from github – Published: 2023-10-04 21:30 – Updated: 2024-04-04 08:18A race condition in an event subsystem led to a heap use-after-free issue in established audio/video calls that could have resulted in app termination or unexpected control flow with very low probability.
{
"affected": [],
"aliases": [
"CVE-2023-38538"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-366"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-04T20:15:10Z",
"severity": "MODERATE"
},
"details": "A race condition in an event subsystem led to a heap use-after-free issue in established audio/video calls that could have resulted in app termination or unexpected control flow with very low probability.",
"id": "GHSA-hr72-3p79-rchw",
"modified": "2024-04-04T08:18:42Z",
"published": "2023-10-04T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38538"
},
{
"type": "WEB",
"url": "https://www.whatsapp.com/security/advisories/2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HR7H-XH5G-347Q
Vulnerability from github – Published: 2023-02-22 18:30 – Updated: 2023-03-06 18:30An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove().
{
"affected": [],
"aliases": [
"CVE-2023-23039"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-22T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove().",
"id": "GHSA-hr7h-xh5g-347q",
"modified": "2023-03-06T18:30:22Z",
"published": "2023-02-22T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23039"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2023/1/1/169"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HRJC-JCQ2-JG57
Vulnerability from github – Published: 2022-07-13 00:00 – Updated: 2022-07-13 00:00Windows DNS Server Remote Code Execution Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-30214"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-12T23:15:00Z",
"severity": "MODERATE"
},
"details": "Windows DNS Server Remote Code Execution Vulnerability.",
"id": "GHSA-hrjc-jcq2-jg57",
"modified": "2022-07-13T00:00:39Z",
"published": "2022-07-13T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30214"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30214"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-30214"
}
],
"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-HRMR-G9X6-F5V8
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-11-16 19:00An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Local attackers can conduct a cache-timing attack against public key operations. These attackers may already have obtained sensitive information if the affected system has been used for private key operations (e.g., signing with a private key).
{
"affected": [],
"aliases": [
"CVE-2020-15309"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-21T14:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Local attackers can conduct a cache-timing attack against public key operations. These attackers may already have obtained sensitive information if the affected system has been used for private key operations (e.g., signing with a private key).",
"id": "GHSA-hrmr-g9x6-f5v8",
"modified": "2022-11-16T19:00:32Z",
"published": "2022-05-24T17:26:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15309"
},
{
"type": "WEB",
"url": "https://arxiv.org/abs/2008.12188"
},
{
"type": "WEB",
"url": "https://github.com/wolfSSL/wolfssl/releases/tag/v4.5.0-stable"
}
],
"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-HRXV-7XRV-H5RV
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
sock_map: avoid race between sock_map_close and sk_psock_put
sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL.
This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it.
That will trigger the WARN_ON_ONCE:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work.
As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted.
After that change, the reproducer does not trigger the WARN_ON_ONCE anymore.
{
"affected": [],
"aliases": [
"CVE-2024-39500"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsock_map: avoid race between sock_map_close and sk_psock_put\n\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\n\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\n\nThat will trigger the WARN_ON_ONCE:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 \u003c0f\u003e 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \u003cTASK\u003e\n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \u003c/TASK\u003e\n\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock-\u003ework.\n\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\n\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.",
"id": "GHSA-hrxv-7xrv-h5rv",
"modified": "2025-11-04T00:30:51Z",
"published": "2024-07-12T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39500"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3627605de498639a3c586c8684d12c89cba11073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4959ffc65a0e94f8acaac20deac49f89e6ded52d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b4647add7d3c8530493f7247d11e257ee425bf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5eabdf17fed2ad41b836bb4055ec36d95e512c50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e946428439a0d2079959f5603256ac51b6047017"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HV7H-P8CM-2F83
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09There is an Incomplete Cleanup Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to authentication bypass.
{
"affected": [],
"aliases": [
"CVE-2021-22428"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-02T17:15:00Z",
"severity": "HIGH"
},
"details": "There is an Incomplete Cleanup Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to authentication bypass.",
"id": "GHSA-hv7h-p8cm-2f83",
"modified": "2022-05-24T19:09:32Z",
"published": "2022-05-24T19:09:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22428"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2021/6"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HV95-X3FC-FRQC
Vulnerability from github – Published: 2022-05-27 00:00 – Updated: 2022-06-09 00:00Description: A race condition was addressed with additional validation. This issue is fixed in macOS Monterey 12.3. A malicious application may be able to modify protected parts of the file system.
{
"affected": [],
"aliases": [
"CVE-2022-26690"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-26T18:15:00Z",
"severity": "MODERATE"
},
"details": "Description: A race condition was addressed with additional validation. This issue is fixed in macOS Monterey 12.3. A malicious application may be able to modify protected parts of the file system.",
"id": "GHSA-hv95-x3fc-frqc",
"modified": "2022-06-09T00:00:29Z",
"published": "2022-05-27T00:00:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26690"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213183"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HVRC-P628-RMRC
Vulnerability from github – Published: 2022-10-01 00:00 – Updated: 2024-03-25 03:31roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report->value is in progress.
{
"affected": [],
"aliases": [
"CVE-2022-41850"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-30T06:15:00Z",
"severity": "MODERATE"
},
"details": "roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report-\u003evalue is in progress.",
"id": "GHSA-hvrc-p628-rmrc",
"modified": "2024-03-25T03:31:43Z",
"published": "2022-10-01T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41850"
},
{
"type": "WEB",
"url": "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20220904193115.GA28134@ubuntu/t/#u"
}
],
"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-HVRM-45R6-MJFJ
Vulnerability from github – Published: 2026-07-21 18:34 – Updated: 2026-07-21 18:34Summary
hono/jsx did not isolate context values per request during server-side rendering. While an async component was suspended on await, its provided context value stayed observable to other requests rendering concurrently, so useContext() could return a value from a different in-flight request.
Details
During server-side rendering, context values were kept in a process-wide structure rather than scoped to each request's render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request's context.
This affects the usual ways request-scoped data is passed through a server-rendered JSX tree:
createContext()/useContext()- the
jsxRenderermiddleware anduseRequestContext()
It arises only when context is read after an await inside an async component while requests render concurrently. Reading context synchronously (before any await), purely synchronous rendering, and client-side (DOM) rendering are not affected.
Impact
Under concurrent requests, a response could be rendered with another request's context. A user may receive HTML rendered for a different user, and an authorization check performed after an await may be evaluated against another user's data.
This may lead to:
- disclosure of rendered output intended for another user
- authorization decisions made with the wrong request's context
- cross-request mixing of session or other request-scoped state
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "4.11.8"
},
{
"fixed": "4.12.27"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59896"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T18:34:19Z",
"nvd_published_at": "2026-07-08T17:17:27Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`hono/jsx` did not isolate context values per request during server-side rendering. While an async component was suspended on `await`, its provided context value stayed observable to other requests rendering concurrently, so `useContext()` could return a value from a different in-flight request.\n\n### Details\n\nDuring server-side rendering, context values were kept in a process-wide structure rather than scoped to each request\u0027s render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request\u0027s context.\n\nThis affects the usual ways request-scoped data is passed through a server-rendered JSX tree:\n\n- `createContext()` / `useContext()`\n- the `jsxRenderer` middleware and `useRequestContext()`\n\nIt arises only when context is read after an `await` inside an async component while requests render concurrently. Reading context synchronously (before any `await`), purely synchronous rendering, and client-side (DOM) rendering are not affected.\n\n### Impact\n\nUnder concurrent requests, a response could be rendered with another request\u0027s context. A user may receive HTML rendered for a different user, and an authorization check performed after an `await` may be evaluated against another user\u0027s data.\n\nThis may lead to:\n\n- disclosure of rendered output intended for another user\n- authorization decisions made with the wrong request\u0027s context\n- cross-request mixing of session or other request-scoped state",
"id": "GHSA-hvrm-45r6-mjfj",
"modified": "2026-07-21T18:34:19Z",
"published": "2026-07-21T18:34:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-hvrm-45r6-mjfj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59896"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/fab3b13639339cbd5ba1166a5b23d9ac30c5f64f"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.12.27"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "hono/jsx does not isolate context per request, leading to cross-request data disclosure"
}
GHSA-HVXR-2FVV-C3WQ
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2023-02-08 18:10A race-condition flaw was discovered in openstack-neutron before 7.2.0-12.1, 8.x before 8.3.0-11.1, 9.x before 9.3.1-2.1, and 10.x before 10.0.2-1.1, where, following a minor overcloud update, neutron security groups were disabled. Specifically, the following were reset to 0: net.bridge.bridge-nf-call-ip6tables and net.bridge.bridge-nf-call-iptables. The race was only triggered by an update, at which point an attacker could access exposed tenant VMs and network resources.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.2.0-12.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.3.0-11.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.3.1-2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.2-1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-7543"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-08T18:10:02Z",
"nvd_published_at": "2018-07-26T14:29:00Z",
"severity": "MODERATE"
},
"details": "A race-condition flaw was discovered in openstack-neutron before 7.2.0-12.1, 8.x before 8.3.0-11.1, 9.x before 9.3.1-2.1, and 10.x before 10.0.2-1.1, where, following a minor overcloud update, neutron security groups were disabled. Specifically, the following were reset to 0: net.bridge.bridge-nf-call-ip6tables and net.bridge.bridge-nf-call-iptables. The race was only triggered by an update, at which point an attacker could access exposed tenant VMs and network resources.",
"id": "GHSA-hvxr-2fvv-c3wq",
"modified": "2023-02-08T18:10:02Z",
"published": "2022-05-13T01:07:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7543"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2447"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2448"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2449"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2450"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2451"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2452"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2017-7543"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1473792"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7543"
},
{
"type": "PACKAGE",
"url": "https://opendev.org/openstack/neutron"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227153412/https://www.securityfocus.com/bid/100237"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenStack Neutron Race Condition vulnerability"
}
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.