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.
2911 vulnerabilities reference this CWE, most recent first.
GHSA-MG76-Q6C5-XF6X
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Connected Devices Platform Service allows an authorized attacker to deny service locally.
{
"affected": [],
"aliases": [
"CVE-2025-54114"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T17:15:57Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Connected Devices Platform Service allows an authorized attacker to deny service locally.",
"id": "GHSA-mg76-q6c5-xf6x",
"modified": "2025-09-09T18:31:21Z",
"published": "2025-09-09T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54114"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54114"
}
],
"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-MG8F-6PJ8-CF5J
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix race between rfkill and nci_unregister_device().
syzbot reported the splat below 0 without a repro.
It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill.
nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev.
The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister().
So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed.
Let's unregister the device from rfkill first in nci_unregister_device().
Note that we cannot call nfc_unregister_device() before nci_close_device() because
1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list
2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked
Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device().
WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-23167"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix race between rfkill and nci_unregister_device().\n\nsyzbot reported the splat below [0] without a repro.\n\nIt indicates that struct nci_dev.cmd_wq had been destroyed before\nnci_close_device() was called via rfkill.\n\nnci_dev.cmd_wq is only destroyed in nci_unregister_device(), which\n(I think) was called from virtual_ncidev_close() when syzbot close()d\nan fd of virtual_ncidev.\n\nThe problem is that nci_unregister_device() destroys nci_dev.cmd_wq\nfirst and then calls nfc_unregister_device(), which removes the\ndevice from rfkill by rfkill_unregister().\n\nSo, the device is still visible via rfkill even after nci_dev.cmd_wq\nis destroyed.\n\nLet\u0027s unregister the device from rfkill first in nci_unregister_device().\n\nNote that we cannot call nfc_unregister_device() before\nnci_close_device() because\n\n 1) nfc_unregister_device() calls device_del() which frees\n all memory allocated by devm_kzalloc() and linked to\n ndev-\u003econn_info_list\n\n 2) nci_rx_work() could try to queue nci_conn_info to\n ndev-\u003econn_info_list which could be leaked\n\nThus, nfc_unregister_device() is split into two functions so we\ncan remove rfkill interfaces only before nci_close_device().\n\n[0]:\nDEBUG_LOCKS_WARN_ON(1)\nWARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349\nWARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349\nWARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349\nModules linked in:\nCPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026\nRIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]\nRIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]\nRIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187\nCode: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d \u003c67\u003e 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f\nRSP: 0018:ffffc9000c767680 EFLAGS: 00010046\nRAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000\nRDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0\nRBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4\nR10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2\nR13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30\nFS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0\nCall Trace:\n \u003cTASK\u003e\n lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868\n touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940\n __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982\n nci_close_device+0x302/0x630 net/nfc/nci/core.c:567\n nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639\n nfc_dev_down+0x152/0x290 net/nfc/core.c:161\n nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179\n rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346\n rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301\n vfs_write+0x29a/0xb90 fs/read_write.c:684\n ksys_write+0x150/0x270 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa59b39acb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9\nRDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007\nRBP: 00007fa59b408bf7 R08: \n---truncated---",
"id": "GHSA-mg8f-6pj8-cf5j",
"modified": "2026-03-18T15:30:40Z",
"published": "2026-02-14T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23167"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/126cd30cad37bc7c2c85fe2df2a522d4edf0a5c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/546eba0b10989de9ccc7fd619e874a30561e2b88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ea4d96419fb20f15a52ce657d49f1e7c91eb7ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3369fc5e6120a72169e71acd72e987907a682af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd4412d5905ee580e96c48360dc98fcd9e6f3208"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2492688bb9fed6ab6e313682c387ae71a66ebae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eaa5da5130deda26420273d4610cf6e4f794ed75"
}
],
"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-MGG8-9PVP-6QCW
Vulnerability from github – Published: 2021-08-25 20:59 – Updated: 2021-08-24 18:01Affected versions of the noise_search crate unconditionally implement Send/Sync for MvccRwLock.
This can lead to data races when types that are either !Send or !Sync (e.g. Rc<T>, Arc<Cell<_>>) are contained inside MvccRwLock and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).
Also, safe APIs of MvccRwLock allow aliasing violations by allowing &T and LockResult<MutexGuard<Box<T>>> to co-exist in conflicting lifetime regions. The APIs of MvccRwLock should either be marked as unsafe or MbccRwLock should be changed to private or pub(crate).
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "noise_search"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-09T17:16:18Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Affected versions of the `noise_search` crate unconditionally implement Send/Sync for `MvccRwLock`.\nThis can lead to data races when types that are either `!Send` or `!Sync` (e.g. `Rc\u003cT\u003e`, `Arc\u003cCell\u003c_\u003e\u003e`) are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).\n\nAlso, safe APIs of `MvccRwLock` allow aliasing violations by allowing `\u0026T` and `LockResult\u003cMutexGuard\u003cBox\u003cT\u003e\u003e\u003e` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate).\n",
"id": "GHSA-mgg8-9pvp-6qcw",
"modified": "2021-08-24T18:01:27Z",
"published": "2021-08-25T20:59:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pipedown/noise/issues/72"
},
{
"type": "PACKAGE",
"url": "https://github.com/pipedown/noise"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0141.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "MvccRwLock allows data races \u0026 aliasing violations",
"withdrawn": "2021-08-24T18:01:27Z"
}
GHSA-MGHX-8493-M9RC
Vulnerability from github – Published: 2022-05-14 01:17 – Updated: 2025-04-20 03:37An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. macOS before 10.12.5 is affected. tvOS before 10.2.1 is affected. watchOS before 3.2.2 is affected. The issue involves the "Kernel" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.
{
"affected": [],
"aliases": [
"CVE-2017-2501"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-22T05:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in certain Apple products. iOS before 10.3.2 is affected. macOS before 10.12.5 is affected. tvOS before 10.2.1 is affected. watchOS before 3.2.2 is affected. The issue involves the \"Kernel\" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.",
"id": "GHSA-mghx-8493-m9rc",
"modified": "2025-04-20T03:37:57Z",
"published": "2022-05-14T01:17:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2501"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207797"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207798"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207800"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207801"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/42054"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98468"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038484"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MH5G-QXXQ-3X3P
Vulnerability from github – Published: 2024-11-26 00:33 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
nvme: tcp: avoid race between queue_lock lock and destroy
Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.
DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfxmutexlock+0x10/0x10 ? lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-53100"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-25T22:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: tcp: avoid race between queue_lock lock and destroy\n\nCommit 76d54bf20cdc (\"nvme-tcp: don\u0027t access released socket during\nerror recovery\") added a mutex_lock() call for the queue-\u003equeue_lock\nin nvme_tcp_get_address(). However, the mutex_lock() races with\nmutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.\n\nDEBUG_LOCKS_WARN_ON(lock-\u003emagic != lock)\nWARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220\nModules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]\nCPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:__mutex_lock+0xcf0/0x1220\nCode: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd \u003c0f\u003e 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1\nRSP: 0018:ffff88811305f760 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001\nRBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341\nR10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058\nFS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n ? __warn.cold+0x5b/0x1af\n ? __mutex_lock+0xcf0/0x1220\n ? report_bug+0x1ec/0x390\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x13/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? __mutex_lock+0xcf0/0x1220\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0xd6a/0x59e0\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]\n nvme_sysfs_show_address+0x81/0xc0 [nvme_core]\n dev_attr_show+0x42/0x80\n ? __asan_memset+0x1f/0x40\n sysfs_kf_seq_show+0x1f0/0x370\n seq_read_iter+0x2cb/0x1130\n ? rw_verify_area+0x3b1/0x590\n ? __mutex_lock+0x433/0x1220\n vfs_read+0x6a6/0xa20\n ? lockdep_hardirqs_on+0x78/0x100\n ? __pfx_vfs_read+0x10/0x10\n ksys_read+0xf7/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n ? __x64_sys_openat+0x105/0x1d0\n do_syscall_64+0x93/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? __pfx_ksys_read+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? do_syscall_64+0x9f/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f9713f55cfa\nCode: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4\n---truncated---",
"id": "GHSA-mh5g-qxxq-3x3p",
"modified": "2025-11-04T00:32:07Z",
"published": "2024-11-26T00:33:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53100"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f946479b326a3cbb193f2b8368aed9269514c35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/782373ba27660ba7d330208cf5509ece6feb4545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/975cb1d2121511584695d0e47fdb90e6782da007"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e15cebc1b21856944b387f4abd03b66bd3d4f027"
},
{
"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-MH8P-Q52P-75QG
Vulnerability from github – Published: 2026-05-11 21:31 – Updated: 2026-05-12 15:31A race condition was addressed with improved handling of symbolic links. This issue is fixed in macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. An app may be able to access Contacts without user consent.
{
"affected": [],
"aliases": [
"CVE-2026-28924"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-11T21:18:54Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with improved handling of symbolic links. This issue is fixed in macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. An app may be able to access Contacts without user consent.",
"id": "GHSA-mh8p-q52p-75qg",
"modified": "2026-05-12T15:31:33Z",
"published": "2026-05-11T21:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28924"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/127115"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/127116"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/127117"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MHCH-RJ8X-4V2P
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49129"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:40Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability",
"id": "GHSA-mhch-rj8x-4v2p",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49129"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49129"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MHX2-29JJ-RXFR
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13A race condition was addressed with improved state handling. This issue is fixed in iOS 14.7, macOS Big Sur 11.5. Opening a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2021-30786"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-08T14:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with improved state handling. This issue is fixed in iOS 14.7, macOS Big Sur 11.5. Opening a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution.",
"id": "GHSA-mhx2-29jj-rxfr",
"modified": "2022-05-24T19:13:42Z",
"published": "2022-05-24T19:13:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30786"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212601"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212602"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-MHXP-XVR8-VWJM
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable vulnerability exists in the signature verification of the firmware update functionality of Circle with Disney. Specially crafted network packets can cause an unsigned firmware to be installed in the device resulting in arbitrary code execution. An attacker can send a series of packets to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-2898"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-07T16:29:00Z",
"severity": "HIGH"
},
"details": "An exploitable vulnerability exists in the signature verification of the firmware update functionality of Circle with Disney. Specially crafted network packets can cause an unsigned firmware to be installed in the device resulting in arbitrary code execution. An attacker can send a series of packets to trigger this vulnerability.",
"id": "GHSA-mhxp-xvr8-vwjm",
"modified": "2022-05-13T01:01:15Z",
"published": "2022-05-13T01:01:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2898"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0405"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MJ6P-44CH-CQ69
Vulnerability from github – Published: 2026-07-06 20:16 – Updated: 2026-07-06 20:16The mkdir utility in uutils coreutils incorrectly applies permissions when using the -m flag by creating a directory with umask-derived permissions (typically 0755) before subsequently changing them to the requested mode via a separate chmod system call. In multi-user environments, this introduces a brief window where a directory intended to be private is accessible to other users, potentially leading to unauthorized data access.
Zellic finding 3.48. Reported in the Zellic uutils coreutils Program Security Assessment (for Canonical, Jan 2026), audited commit 3a07ffc5a9bd4c283e75afa548ba1f1957bad242.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "uu_mkdir"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35353"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:16:16Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The mkdir utility in uutils coreutils incorrectly applies permissions when using the -m flag by creating a directory with umask-derived permissions (typically 0755) before subsequently changing them to the requested mode via a separate chmod system call. In multi-user environments, this introduces a brief window where a directory intended to be private is accessible to other users, potentially leading to unauthorized data access.\n\n---\n_Zellic finding 3.48. Reported in the Zellic *uutils coreutils Program Security Assessment* (for Canonical, Jan 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`._",
"id": "GHSA-mj6p-44ch-cq69",
"modified": "2026-07-06T20:16:16Z",
"published": "2026-07-06T20:16:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/security/advisories/GHSA-mj6p-44ch-cq69"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35353"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/pull/10036"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/commit/037b9583bc03d814e8516df54ebcda6f681fe1f8"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/releases/tag/0.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "mkdir: -m exposes directory with umask perms before chmod (race window)"
}
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.