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.
3579 vulnerabilities reference this CWE, most recent first.
GHSA-5464-6852-R995
Vulnerability from github – Published: 2024-05-02 15:30 – Updated: 2024-05-02 15:30The affected AutomationManager.AgentService.exe application contains a TOCTOU race condition vulnerability that allows standard users to create a pseudo-symlink at C:\ProgramData\N-Able Technologies\AutomationManager\Temp, which could be leveraged by an attacker to manipulate the process into performing arbitrary file deletions. We recommend upgrading to version 2.91.0.0
{
"affected": [],
"aliases": [
"CVE-2023-37244"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-02T14:15:09Z",
"severity": "MODERATE"
},
"details": "The affected AutomationManager.AgentService.exe application contains a TOCTOU race condition vulnerability that allows standard users to create a pseudo-symlink at C:\\ProgramData\\N-Able Technologies\\AutomationManager\\Temp, which could be leveraged by an attacker to manipulate the process into performing arbitrary file deletions. We recommend upgrading to version 2.91.0.0",
"id": "GHSA-5464-6852-r995",
"modified": "2024-05-02T15:30:33Z",
"published": "2024-05-02T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37244"
},
{
"type": "WEB",
"url": "https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2023/MNDT-2023-0016.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-547X-8CMF-V92W
Vulnerability from github – Published: 2025-03-17 18:31 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
{
"affected": [],
"aliases": [
"CVE-2022-49443"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u003erdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u003erdllist is empty by list_empty_careful(), which reads\nrdllist-\u003eprev. Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\"epoll: Add busy poll support to epoll with socket\nfds.\") added the first lockless ep_events_available(), and commit\nc5a282e9635e (\"fs/epoll: reduce the scope of wq lock in epoll_wait()\")\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\"epoll: eliminate unnecessary lock\nfor zero timeout\") made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u003e 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011",
"id": "GHSA-547x-8cmf-v92w",
"modified": "2025-03-17T18:31:47Z",
"published": "2025-03-17T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49443"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d5d993f16be15d124be7b8ec71b28ef7b7dc3af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb3e48f7a35033deb9455abe3932e63cb500b9eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d679ae94fdd5d3ab00c35078f5af5f37e068b03d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e039c0b5985999b150594126225e1ee51df7b4c9"
}
],
"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-54FG-M6MQ-PRVP
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in Windows USB Print Driver allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-49806"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T17:16:57Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows USB Print Driver allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-54fg-m6mq-prvp",
"modified": "2026-07-14T18:32:03Z",
"published": "2026-07-14T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49806"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-49806"
}
],
"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-54RH-2MJP-CVMQ
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46In FreeBSD 13.0-STABLE before n245118, 12.2-STABLE before r369552, 11.4-STABLE before r369560, 13.0-RC5 before p1, 12.2-RELEASE before p6, and 11.4-RELEASE before p9, a superuser inside a FreeBSD jail configured with the non-default allow.mount permission could cause a race condition between the lookup of ".." and remounting a filesystem, allowing access to filesystem hierarchy outside of the jail.
{
"affected": [],
"aliases": [
"CVE-2020-25584"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-07T15:15:00Z",
"severity": "HIGH"
},
"details": "In FreeBSD 13.0-STABLE before n245118, 12.2-STABLE before r369552, 11.4-STABLE before r369560, 13.0-RC5 before p1, 12.2-RELEASE before p6, and 11.4-RELEASE before p9, a superuser inside a FreeBSD jail configured with the non-default allow.mount permission could cause a race condition between the lookup of \"..\" and remounting a filesystem, allowing access to filesystem hierarchy outside of the jail.",
"id": "GHSA-54rh-2mjp-cvmq",
"modified": "2022-05-24T17:46:44Z",
"published": "2022-05-24T17:46:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25584"
},
{
"type": "WEB",
"url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-21:10.jail_mount.asc"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210423-0009"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-54RX-JMRP-J5MW
Vulnerability from github – Published: 2026-10-21 15:42 – Updated: 2026-10-21 15:42A data race in the RDMA transport of Apache bRPC (versions < 1.18.0) allows a remote client to crash the server process (denial of service) when RDMA is enabled at build time and runtime.
Root Cause: When a bRPC server negotiates RDMA with a client, the handshake completes on the TCP fd, but the server kept parsing that fd afterwards as if it were still an RPC channel. The TCP-fd input stream and the RDMA QP input stream (driven by CQ events) shared the same Socket::_read_buf, preferred_index and parsing_context without synchronization. In addition, CQ event processing could start while the handshake parsing was still in progress, and the handshake ACK phase could consume bytes belonging to the next protocol. A remote, unauthenticated client that has completed the RDMA handshake can send data on the TCP fd at the same time RDMA messages are being processed, corrupting the shared input buffer and parser state and crashing the server process (CWE-362, availability impact).
Affected Scenarios: Use a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA and serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections from untrusted clients. Deployments without RDMA are not affected.
How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3505
{
"affected": [],
"aliases": [
"CVE-2026-82942"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-21T13:20:03Z",
"severity": null
},
"details": "A data race in the RDMA transport of Apache bRPC (versions \u003c 1.18.0) allows a remote client to crash the server process (denial of service) when RDMA is enabled at build time and runtime.\n\nRoot Cause:\nWhen a bRPC server negotiates RDMA with a client, the handshake completes on the TCP fd, but the server kept parsing that fd afterwards as if it were still an RPC channel. The TCP-fd input stream and the RDMA QP input stream (driven by CQ events) shared the same Socket::_read_buf, preferred_index and parsing_context without synchronization. In addition, CQ event processing could start while the handshake parsing was still in progress, and the handshake ACK phase could consume bytes belonging to the next protocol. A remote, unauthenticated client that has completed the RDMA handshake can send data on the TCP fd at the same time RDMA messages are being processed, corrupting the shared input buffer and parser state and crashing the server process (CWE-362, availability impact).\n\nAffected Scenarios:\nUse a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA and serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections from untrusted clients. Deployments without RDMA are not affected.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3505",
"id": "GHSA-54rx-jmrp-j5mw",
"modified": "2026-10-21T15:42:28Z",
"published": "2026-10-21T15:42:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82942"
},
{
"type": "WEB",
"url": "https://github.com/apache/brpc/issues/3479"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-54XP-779J-4C34
Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2024-08-13 18:31Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-38137"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T18:15:17Z",
"severity": "HIGH"
},
"details": "Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability",
"id": "GHSA-54xp-779j-4c34",
"modified": "2024-08-13T18:31:16Z",
"published": "2024-08-13T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38137"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38137"
}
],
"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-552G-3PCR-RJ34
Vulnerability from github – Published: 2026-03-25 03:31 – Updated: 2026-03-25 15:31A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4. An app may be able to cause unexpected system termination.
{
"affected": [],
"aliases": [
"CVE-2026-28834"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T01:17:08Z",
"severity": "MODERATE"
},
"details": "A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4. An app may be able to cause unexpected system termination.",
"id": "GHSA-552g-3pcr-rj34",
"modified": "2026-03-25T15:31:28Z",
"published": "2026-03-25T03:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28834"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126794"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126795"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126796"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-553F-PJFM-RX99
Vulnerability from github – Published: 2022-05-14 00:58 – Updated: 2022-05-14 00:58The Linux kernel before 4.8 allows local users to bypass ASLR on setuid programs (such as /bin/su) because install_exec_creds() is called too late in load_elf_binary() in fs/binfmt_elf.c, and thus the ptrace_may_access() check has a race condition when reading /proc/pid/stat.
{
"affected": [],
"aliases": [
"CVE-2019-11190"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-12T00:29:00Z",
"severity": "MODERATE"
},
"details": "The Linux kernel before 4.8 allows local users to bypass ASLR on setuid programs (such as /bin/su) because install_exec_creds() is called too late in load_elf_binary() in fs/binfmt_elf.c, and thus the ptrace_may_access() check has a race condition when reading /proc/pid/stat.",
"id": "GHSA-553f-pjfm-rx99",
"modified": "2022-05-14T00:58:54Z",
"published": "2022-05-14T00:58:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11190"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=a5b5352558f6808db0589644ea5401b3e3148a0d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=e1676b55d874a43646e8b2c46d87f2f3e45516ff"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00041.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00042.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4008-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4008-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4008-3"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2019/04/03/4"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2019/04/03/4/1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00039.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/15/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107890"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-557M-FHM3-G2JC
Vulnerability from github – Published: 2026-07-30 03:31 – Updated: 2026-07-31 18:32Race in Chrome for iOS in Google Chrome on iOS prior to 151.0.7922.72 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-17822"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T01:16:45Z",
"severity": "MODERATE"
},
"details": "Race in Chrome for iOS in Google Chrome on iOS prior to 151.0.7922.72 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-557m-fhm3-g2jc",
"modified": "2026-07-31T18:32:11Z",
"published": "2026-07-30T03:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17822"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/517621178"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-559G-J59R-PXG6
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:32In the Linux kernel, the following vulnerability has been resolved:
rbd: eliminate a race in lock_dwork draining on unmap
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.
A more problematic example is maybe_kick_acquire():
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}
It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.
When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().
Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().
{
"affected": [],
"aliases": [
"CVE-2026-64112"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:52Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrbd: eliminate a race in lock_dwork draining on unmap\n\nGiven how rbd_lock_add_request() and rbd_img_exclusive_lock() are\nwritten, lock_dwork may be (re)queued more than it\u0027s actually needed:\nfor example in case a new I/O request comes in while we are in the\nmiddle of rbd_acquire_lock() on behalf of another I/O request. This is\nexpected and with rbd_release_lock() preemptively canceling lock_dwork\nis benign under normal operation.\n\nA more problematic example is maybe_kick_acquire():\n\n if (have_requests || delayed_work_pending(\u0026rbd_dev-\u003elock_dwork)) {\n dout(\"%s rbd_dev %p kicking lock_dwork\\n\", __func__, rbd_dev);\n mod_delayed_work(rbd_dev-\u003etask_wq, \u0026rbd_dev-\u003elock_dwork, 0);\n }\n\nIt\u0027s not unrealistic for lock_dwork to get canceled right after\ndelayed_work_pending() returns true and for mod_delayed_work() to\nrequeue it right there anyway. This is a classic TOCTOU race.\n\nWhen it comes to unmapping the image, there is an implicit assumption\nof no self-initiated exclusive lock activity past the point of return\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be\nheld. This unlock is assumed to be final and lock_dwork (as well as\nall other exclusive lock tasks, really) isn\u0027t expected to get queued\nagain. However, lock_dwork is canceled only in cancel_tasks_sync()\n(i.e. later in the unmap sequence) and on top of that the cancellation\ncan get in effect nullified by maybe_kick_acquire(). This may result\nin rbd_acquire_lock() executing after rbd_dev_device_release() and\nrbd_dev_image_release() run and free and/or reset a bunch of things.\nOne of the possible failure modes then is a violated\n\n rbd_assert(rbd_image_format_valid(rbd_dev-\u003eimage_format));\n\nin rbd_dev_header_info() which is called via rbd_dev_refresh() from\nrbd_post_acquire_action().\n\nRedo exclusive lock task draining to provide saner semantics and try\nto meet the assumptions around rbd_dev_image_unlock().",
"id": "GHSA-559g-j59r-pxg6",
"modified": "2026-07-20T15:32:00Z",
"published": "2026-07-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64112"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90"
}
],
"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"
}
]
}
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.