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.
3591 vulnerabilities reference this CWE, most recent first.
GHSA-7768-MFM4-9CMV
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22When browsing a malicious page, a race condition in our SharedWorkerService could occur and lead to a potentially exploitable crash. This vulnerability affects Thunderbird < 68.9.0, Firefox < 77, and Firefox ESR < 68.9.
{
"affected": [],
"aliases": [
"CVE-2020-12405"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-09T15:15:00Z",
"severity": "LOW"
},
"details": "When browsing a malicious page, a race condition in our SharedWorkerService could occur and lead to a potentially exploitable crash. This vulnerability affects Thunderbird \u003c 68.9.0, Firefox \u003c 77, and Firefox ESR \u003c 68.9.",
"id": "GHSA-7768-mfm4-9cmv",
"modified": "2022-05-24T17:22:37Z",
"published": "2022-05-24T17:22:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12405"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1631618"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4421-1"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-20"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-21"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-22"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-77F5-F59V-G352
Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data races in proc_douintvec().
A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing.
This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
{
"affected": [],
"aliases": [
"CVE-2022-49641"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsysctl: Fix data races in proc_douintvec().\n\nA sysctl variable is accessed concurrently, and there is always a chance\nof data-race. So, all readers and writers need some basic protection to\navoid load/store-tearing.\n\nThis patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()\ninternally to fix data-races on the sysctl side. For now, proc_douintvec()\nitself is tolerant to a data-race, but we still need to add annotations on\nthe other subsystem\u0027s side.",
"id": "GHSA-77f5-f59v-g352",
"modified": "2025-03-12T00:31:48Z",
"published": "2025-03-12T00:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49641"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4762b532ec9539755aab61445d5da6e1926ccb99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/630c76850d554d7140232e71b5d1663e88cffb54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d335db59f7fb3353f56e52371f1ee796ae9c8f09"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5d54714e329f646bd7af4994fc427d88ee68936"
}
],
"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-77G8-PQ4G-F4JV
Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-10-01 00:00An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.
{
"affected": [],
"aliases": [
"CVE-2020-25604"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-23T22:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn\u0027t acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.",
"id": "GHSA-77g8-pq4g-f4jv",
"modified": "2022-10-01T00:00:25Z",
"published": "2022-05-24T17:29:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25604"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4JRXMKEMQRQYWYEPHVBIWUEAVQ3LU4FN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DA633Y3G5KX7MKRN4PFEGM3IVTJMBEOM"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RJZERRBJN6E6STDCHT4JHP4MI6TKBCJE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202011-06"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4769"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-336.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00008.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-77M6-X95J-75R5
Vulnerability from github – Published: 2021-08-25 20:58 – Updated: 2023-06-13 22:07Affected versions of this crate unconditionally implemented Send for ReadTicket & WriteTicket. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads (as T of ReadTicket/WriteTicket). Such data races can cause memory corruption or other undefined behavior. The flaw was corrected in commit a986a93 by adding T: Send bounds to Send impls of ReadTicket/WriteTicket.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ticketed_lock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36439"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-09T22:40:34Z",
"nvd_published_at": "2021-08-08T06:15:00Z",
"severity": "HIGH"
},
"details": "Affected versions of this crate unconditionally implemented Send for ReadTicket\u003cT\u003e \u0026 WriteTicket\u003cT\u003e. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads (as T of ReadTicket\u003cT\u003e/WriteTicket\u003cT\u003e). Such data races can cause memory corruption or other undefined behavior. The flaw was corrected in commit `a986a93` by adding T: Send bounds to Send impls of ReadTicket\u003cT\u003e/WriteTicket\u003cT\u003e.",
"id": "GHSA-77m6-x95j-75r5",
"modified": "2023-06-13T22:07:15Z",
"published": "2021-08-25T20:58:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36439"
},
{
"type": "WEB",
"url": "https://github.com/kvark/ticketed_lock/issues/7"
},
{
"type": "WEB",
"url": "https://github.com/kvark/ticketed_lock/commit/a986a9335d591fa5c826157d1674d47aa525357f"
},
{
"type": "WEB",
"url": "https://github.com/kvark/ticketed_lock"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/ticketed_lock/RUSTSEC-2020-0119.md"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0119.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 ticketed_lock"
}
GHSA-77P3-MMMP-FJJ2
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-12 21:31In the Linux kernel, the following vulnerability has been resolved:
io_uring/zcrx: fix user_ref race between scrub and refill paths
The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock.
On SMP systems, the following race exists:
CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock) put_niov_uref: atomic_read(uref) - 1 // window opens atomic_xchg(uref, 0) - 1 return_niov_freelist(niov) [PUSH #1] // window closes atomic_dec(uref) - wraps to -1 returns true return_niov(niov) return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]
The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object.
Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock.
[pavel: removed a warning and a comment]
{
"affected": [],
"aliases": [
"CVE-2026-43121"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/zcrx: fix user_ref race between scrub and refill paths\n\nThe io_zcrx_put_niov_uref() function uses a non-atomic\ncheck-then-decrement pattern (atomic_read followed by separate\natomic_dec) to manipulate user_refs. This is serialized against other\ncallers by rq_lock, but io_zcrx_scrub() modifies the same counter with\natomic_xchg() WITHOUT holding rq_lock.\n\nOn SMP systems, the following race exists:\n\n CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock)\n put_niov_uref:\n atomic_read(uref) - 1\n // window opens\n atomic_xchg(uref, 0) - 1\n return_niov_freelist(niov) [PUSH #1]\n // window closes\n atomic_dec(uref) - wraps to -1\n returns true\n return_niov(niov)\n return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]\n\nThe same niov is pushed to the freelist twice, causing free_count to\nexceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds\nwrite (a u32 value) past the kvmalloc\u0027d freelist array into the adjacent\nslab object.\n\nFix this by replacing the non-atomic read-then-dec in\nio_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically\ntests and decrements user_refs. This makes the operation safe against\nconcurrent atomic_xchg from scrub without requiring scrub to acquire\nrq_lock.\n\n[pavel: removed a warning and a comment]",
"id": "GHSA-77p3-mmmp-fjj2",
"modified": "2026-05-12T21:31:26Z",
"published": "2026-05-06T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43121"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/003049b1c4fb8aabb93febb7d1e49004f6ad653b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/485dc691257b96e6d3bdc25b0eff2daadcc5c46c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a94f096e28bfc7975163a6b80f1c8f323efe317a"
}
],
"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-77QF-55VF-5V3V
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix potential race condition between napi_init and napi_enable
A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON():
kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0
To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw().
{
"affected": [],
"aliases": [
"CVE-2023-53452"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix potential race condition between napi_init and napi_enable\n\nA race condition can happen if netdev is registered, but NAPI isn\u0027t\ninitialized yet, and meanwhile user space starts the netdev that will\nenable NAPI. Then, it hits BUG_ON():\n\n kernel BUG at net/core/dev.c:6423!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91\n Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022\n RIP: 0010:napi_enable+0x3f/0x50\n Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...\n RSP: 0018:ffffada1414f3548 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000\n RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58\n R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001\n FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n \u003cTASK\u003e\n rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]\n rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n __dev_open+0xe0/0x180\n __dev_change_flags+0x1da/0x250\n dev_change_flags+0x26/0x70\n do_setlink+0x37c/0x12c0\n ? ep_poll_callback+0x246/0x290\n ? __nla_validate_parse+0x61/0xd00\n ? __wake_up_common_lock+0x8f/0xd0\n\nTo fix this, follow Jonas\u0027 suggestion to switch the order of these\nfunctions and move register netdev to be the last step of PCI probe.\nAlso, correct the error handling of rtw89_core_register_hw().",
"id": "GHSA-77qf-55vf-5v3v",
"modified": "2026-01-16T21:30:29Z",
"published": "2025-10-01T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53452"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39712c8aeb79691bcec8bd6ff658cde1651e0803"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47515664ecfbde11425dff121f298ae4499425c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa48073c2f993e1b0c0bc66b03ae105cac0130bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1b90c7df08ef385f95827ee3aee87bddd1ef5c5"
}
],
"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-77RM-8JVR-HFGM
Vulnerability from github – Published: 2024-09-16 18:31 – Updated: 2025-11-04 00:31A race condition in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2023-41833"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-16T17:15:59Z",
"severity": "HIGH"
},
"details": "A race condition in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.",
"id": "GHSA-77rm-8jvr-hfgm",
"modified": "2025-11-04T00:31:25Z",
"published": "2024-09-16T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41833"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241011-0009"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01071.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-78FW-H7FP-FFFH
Vulnerability from github – Published: 2026-03-18 12:31 – Updated: 2026-04-02 15:31In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix refcount bug and potential UAF in perf_mmap
Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap.
The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).
In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event->rb with the mmap_mutex held. The mutex is then released to perform map_range().
If map_range() fails, perf_mmap_close() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.
Fix this by extending the scope of mmap_mutex to cover the map_range() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.
{
"affected": [],
"aliases": [
"CVE-2026-23248"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-18T11:16:16Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix refcount bug and potential UAF in perf_mmap\n\nSyzkaller reported a refcount_t: addition on 0; use-after-free warning\nin perf_mmap.\n\nThe issue is caused by a race condition between a failing mmap() setup\nand a concurrent mmap() on a dependent event (e.g., using output\nredirection).\n\nIn perf_mmap(), the ring_buffer (rb) is allocated and assigned to\nevent-\u003erb with the mmap_mutex held. The mutex is then released to\nperform map_range().\n\nIf map_range() fails, perf_mmap_close() is called to clean up.\nHowever, since the mutex was dropped, another thread attaching to\nthis event (via inherited events or output redirection) can acquire\nthe mutex, observe the valid event-\u003erb pointer, and attempt to\nincrement its reference count. If the cleanup path has already\ndropped the reference count to zero, this results in a\nuse-after-free or refcount saturation warning.\n\nFix this by extending the scope of mmap_mutex to cover the\nmap_range() call. This ensures that the ring buffer initialization\nand mapping (or cleanup on failure) happens atomically effectively,\npreventing other threads from accessing a half-initialized or\ndying ring buffer.",
"id": "GHSA-78fw-h7fp-fffh",
"modified": "2026-04-02T15:31:36Z",
"published": "2026-03-18T12:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23248"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77de62ad3de3967818c3dbe656b7336ebee461d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac7ecb65af170a7fc193e7bd8be15dac84ec6a56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c27dea9f50ed525facb62ef647dddc4722456e07"
}
],
"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-78P8-M8PR-GVC2
Vulnerability from github – Published: 2025-09-19 00:30 – Updated: 2025-09-19 00:30Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-59216"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T22:15:49Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-78p8-m8pr-gvc2",
"modified": "2025-09-19T00:30:58Z",
"published": "2025-09-19T00:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59216"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59216"
}
],
"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-78PH-MC3Q-52VV
Vulnerability from github – Published: 2026-07-29 18:31 – Updated: 2026-10-15 03:36In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: Prevent UAF caused by non-leader exec() race
Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF:
sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL;
// Returns without action if(!sighand) return 0; free_posix_timer();
This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited.
As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF.
There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack.
Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire.
While debating solutions Frederic pointed out another problem:
posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand);
if (!sh)
WARN_ON_ONCE(timer_queued(tmr));
On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive.
Solve these issues by:
1) Changing the store in __exit_signal() to smp_store_release().
2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand().
3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up.
4) Using that helper in the three affected functions.
1/#2 ensures that the reader side which observes sighand == NULL also
observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task().
3 ensures that the above described non-leader exec() situation is handled
gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails.
When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible.
The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which surv ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-64560"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-29T17:16:53Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-cpu-timers: Prevent UAF caused by non-leader exec() race\n\nWongi and Jungwoo decoded and reported a non-leader exec() related race\nwhich can result in an UAF:\n\n sys_timer_delete()\t\t\texec()\n posix_cpu_timer_del()\n // Observes old leader\n p = pid_task(pid, pid_type);\t\tde_thread()\n \t\t\t\t\t switch_leader();\n\t\t\t\t\t release_task(old_leader)\n\t\t\t\t\t __exit_signal(old_leader)\n\t\t\t\t\t sighand = lock(old_leader, sighand);\n\t\t\t\t\t posix_cpu_timers*_exit();\n sighand = lock_task_sighand(p)\t unhash_task(old_leader);\n sh = lock(p, sighand)\t \t old_leader-\u003esighand = NULL;\n\t\t\t\t\t unlock(sighand);\n (p-\u003esighand == NULL)\n\tunlock(sh)\n\treturn NULL;\n\n // Returns without action\n if(!sighand)\n return 0;\n free_posix_timer();\n\nThis is \"harmless\" unless the deleted timer was armed and enqueued in\np-\u003esignal because on exec() a TGID targeted timer is inherited.\n\nAs sys_timer_delete() freed the underlying posix timer object\nrun_posix_cpu_timers() or any timerqueue related add/delete operations on\nother timers will access the freed object\u0027s timerqueue node, which results\nin an UAF.\n\nThere is a similar problem vs. posix_cpu_timer_set(). For regular posix\ntimers it just transiently returns -ESRCH to user space, but for the use\ncase in do_cpu_nanosleep() it\u0027s the same UAF just that the k_itimer is\nallocated on the stack.\n\nAlso posix_cpu_timer_rearm() fails to rearm the timer, which means it stops\nto expire.\n\nWhile debating solutions Frederic pointed out another problem:\n\n posix_cpu_timer_del(tmr)\n\t\t\t\t\t__exit_signal(p)\n\t\t\t\t\t posix_cpu_timers*_exit(p);\n\t\t\t\t\t unhash_task(p);\n\t\t\t\t\t p-\u003esighand = NULL;\n sh = lock_task_sighand(p)\n sighand = p-\u003esighand;\n\tif (!sighand)\n\t return NULL;\n\tlock(sighand);\n\n if (!sh)\n\tWARN_ON_ONCE(timer_queued(tmr));\n\nOn weakly ordered architectures it is not guaranteed that\nposix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit()\nwhen p-\u003esighand is observed as NULL, which means the WARN() can be a false\npositive.\n\nSolve these issues by:\n\n 1) Changing the store in __exit_signal() to smp_store_release().\n\n 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path\n of lock_task_sighand().\n\n 3) Creating a helper function for looking up the task and locking sighand\n which does not return when sighand == NULL. Instead it retries the\n task lookup and only if that fails it gives up.\n\n 4) Using that helper in the three affected functions.\n\n#1/#2 ensures that the reader side which observes sighand == NULL also\nobserves all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()\nand the ones in unhash_task().\n\n#3 ensures that the above described non-leader exec() situation is handled\ngracefully. When the task lookup returns the old leader, but sighand ==\nNULL then it retries. In the non-leader exec() case the subsequent task\nlookup will observe the new leader due to #1/#2. In normal exit() scenarios\nthe subsequent lookup fails.\n\nWhen the task lookup fails, the function also checks whether the timer is\nstill enqueued and issues a warning if that\u0027s the case. Unfortunately there\nis nothing which can be done about it, but as the task is already not\nlonger visible the timer should not be accessed anymore. This check also\nrequires memory ordering, which is not provided when the first lookup\nfails. To achieve that the check is preceeded by a smp_rmb() which pairs\nwith the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that\nthe stores in posix_cpu_timers*_exit() are visible.\n\nThe history of the non-leader exec() issue goes back to the early days of\nposix CPU timers, which stored a pointer to the group leader task in the\ntimer. That obviously fails when a non-leader exec() switches the leader.\ncommit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems\nwith mt exec\") added a temporary workaround for that in 2010 which surv\n---truncated---",
"id": "GHSA-78ph-mc3q-52vv",
"modified": "2026-10-15T03:36:22Z",
"published": "2026-07-29T18:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64560"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12a891c773aeb5823d63dbd0cb2ab931d6c21c9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67aa823e3e8c229c6d374df79c804f6721cb83b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a7ecc25abe6f0fecc6e62a05096987200edbd02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/920f893f735e92ba3a1cd9256899a186b161928d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad1cafa1bdaa71da85d71cac053838bbe97852b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc35ddbc497311e0b6b9a6a6a4f4d1217d6ab1aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8bcb28abad857f1415da7656f19b2ada90af04f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e74443f5db0037c556ef436fa64b88bf4ea08f83"
}
],
"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.