CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
721 vulnerabilities reference this CWE, most recent first.
GHSA-9X65-M9RH-PQXF
Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
bcachefs: grab s_umount only if snapshotting
When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume.
$ cat test.sh prog=bcachefs
$prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots
while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done
$ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log
storage: dbPath: /mnt/data/
lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] ------------------------------------------------------ [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock.
[ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshot_create_lock){++++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notify_change+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 3437.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){.+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] filename_create+0x62/0x190 [ 3437.466175] user_path_create+0x2d/0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this:
[ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this:
[ 3437.467507] Chain exists of: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48
[ 3437.467979] Possible unsafe locking scenario:
[ 3437.468223] CPU0 CPU1 [ 3437.468405] ---- ---- [ 3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] lock(&c->snapshot_create_lock); [ 3437.469030] lock(&type->s_umount_key#48); [ 3437.469291] rlock(sb_writers#10); [ 3437.469434] *** DEADLOCK ***
[ 3437.469 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26658"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcachefs: grab s_umount only if snapshotting\n\nWhen I was testing mongodb over bcachefs with compression,\nthere is a lockdep warning when snapshotting mongodb data volume.\n\n$ cat test.sh\nprog=bcachefs\n\n$prog subvolume create /mnt/data\n$prog subvolume create /mnt/data/snapshots\n\nwhile true;do\n $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)\n sleep 1s\ndone\n\n$ cat /etc/mongodb.conf\nsystemLog:\n destination: file\n logAppend: true\n path: /mnt/data/mongod.log\n\nstorage:\n dbPath: /mnt/data/\n\nlockdep reports:\n[ 3437.452330] ======================================================\n[ 3437.452750] WARNING: possible circular locking dependency detected\n[ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E\n[ 3437.453562] ------------------------------------------------------\n[ 3437.453981] bcachefs/35533 is trying to acquire lock:\n[ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190\n[ 3437.454875]\n but task is already holding lock:\n[ 3437.455268] ffffa0a02b2b10e0 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.456009]\n which lock already depends on the new lock.\n\n[ 3437.456553]\n the existing dependency chain (in reverse order) is:\n[ 3437.457054]\n -\u003e #3 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}:\n[ 3437.457507] down_read+0x3e/0x170\n[ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.458206] __x64_sys_ioctl+0x93/0xd0\n[ 3437.458498] do_syscall_64+0x42/0xf0\n[ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.459155]\n -\u003e #2 (\u0026c-\u003esnapshot_create_lock){++++}-{3:3}:\n[ 3437.459615] down_read+0x3e/0x170\n[ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]\n[ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]\n[ 3437.460686] notify_change+0x1f1/0x4a0\n[ 3437.461283] do_truncate+0x7f/0xd0\n[ 3437.461555] path_openat+0xa57/0xce0\n[ 3437.461836] do_filp_open+0xb4/0x160\n[ 3437.462116] do_sys_openat2+0x91/0xc0\n[ 3437.462402] __x64_sys_openat+0x53/0xa0\n[ 3437.462701] do_syscall_64+0x42/0xf0\n[ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.463359]\n -\u003e #1 (\u0026sb-\u003es_type-\u003ei_mutex_key#15){+.+.}-{3:3}:\n[ 3437.463843] down_write+0x3b/0xc0\n[ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]\n[ 3437.464493] vfs_write+0x21b/0x4c0\n[ 3437.464653] ksys_write+0x69/0xf0\n[ 3437.464839] do_syscall_64+0x42/0xf0\n[ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.465231]\n -\u003e #0 (sb_writers#10){.+.+}-{0:0}:\n[ 3437.465471] __lock_acquire+0x1455/0x21b0\n[ 3437.465656] lock_acquire+0xc6/0x2b0\n[ 3437.465822] mnt_want_write+0x46/0x1a0\n[ 3437.465996] filename_create+0x62/0x190\n[ 3437.466175] user_path_create+0x2d/0x50\n[ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]\n[ 3437.466617] __x64_sys_ioctl+0x93/0xd0\n[ 3437.466791] do_syscall_64+0x42/0xf0\n[ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.467180]\n other info that might help us debug this:\n\n[ 3437.469670] 2 locks held by bcachefs/35533:\n other info that might help us debug this:\n\n[ 3437.467507] Chain exists of:\n sb_writers#10 --\u003e \u0026c-\u003esnapshot_create_lock --\u003e \u0026type-\u003es_umount_key#48\n\n[ 3437.467979] Possible unsafe locking scenario:\n\n[ 3437.468223] CPU0 CPU1\n[ 3437.468405] ---- ----\n[ 3437.468585] rlock(\u0026type-\u003es_umount_key#48);\n[ 3437.468758] lock(\u0026c-\u003esnapshot_create_lock);\n[ 3437.469030] lock(\u0026type-\u003es_umount_key#48);\n[ 3437.469291] rlock(sb_writers#10);\n[ 3437.469434]\n *** DEADLOCK ***\n\n[ 3437.469\n---truncated---",
"id": "GHSA-9x65-m9rh-pqxf",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-02T09:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2acc59dd88d27ad69b66ded80df16c042b04eeec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b41d3fd04c6757b9c2a60a0c5b2609cae9999df"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9X8P-G64X-M5J5
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-12 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix deadlock between rcu_tasks_trace and event_mutex.
Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()
There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case.
CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)
Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.
{
"affected": [],
"aliases": [
"CVE-2025-37884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock between rcu_tasks_trace and event_mutex.\n\nFix the following deadlock:\nCPU A\n_free_event()\n perf_kprobe_destroy()\n mutex_lock(\u0026event_mutex)\n perf_trace_event_unreg()\n synchronize_rcu_tasks_trace()\n\nThere are several paths where _free_event() grabs event_mutex\nand calls sync_rcu_tasks_trace. Above is one such case.\n\nCPU B\nbpf_prog_test_run_syscall()\n rcu_read_lock_trace()\n bpf_prog_run_pin_on_cpu()\n bpf_prog_load()\n bpf_tracing_func_proto()\n trace_set_clr_event()\n mutex_lock(\u0026event_mutex)\n\nDelegate trace_set_clr_event() to workqueue to avoid\nsuch lock dependency.",
"id": "GHSA-9x8p-g64x-m5j5",
"modified": "2025-11-12T21:31:03Z",
"published": "2025-05-09T09:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/255cbc9db7067a83713fd2f4b31034ddd266549a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45286680b385f2592db3003554872388dee66d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4580f4e0ebdf8dc8d506ae926b88510395a0c1d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5a528a34e1f613565115a7a6016862ccbfcb9ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5c833f6375f8ecf9254dd27946c927c7d645421"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9XMP-2MMM-6X5G
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A
{
"affected": [],
"aliases": [
"CVE-2020-0423"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-14T14:15:00Z",
"severity": "HIGH"
},
"details": "In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A",
"id": "GHSA-9xmp-2mmm-6x5g",
"modified": "2022-05-24T17:30:38Z",
"published": "2022-05-24T17:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0423"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00015.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-10-01"
}
],
"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-9XQ7-8P44-P7P4
Vulnerability from github – Published: 2026-06-18 15:32 – Updated: 2026-06-18 18:35[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.
{
"affected": [],
"aliases": [
"CVE-2026-42490"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-18T14:17:25Z",
"severity": "MODERATE"
},
"details": "[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nTo create and manage guests, domctl operations are used by the control\ndomain, a possible Xenstore domain, or by a domain controlling a\nparticular guest. Some of these operations may not be executed in\nparallel, so a system-wide lock is used. The way that lock is acquired\nis, however, not providing any fairness. This is CVE-2026-42489.\n\nFurthermore, with XSM/Flask in use, the lock acquire will, for some\noperations, occur ahead of any permission checking. This is\nCVE-2026-42490.",
"id": "GHSA-9xq7-8p44-p7p4",
"modified": "2026-06-18T18:35:21Z",
"published": "2026-06-18T15:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42490"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-492.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C2CR-W322-FPPQ
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup during bt pages loop
Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup:
watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
...
Call trace:
hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x118/0x290
watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
...
Call trace:
hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x120/0x2bc
Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched().
{
"affected": [],
"aliases": [
"CVE-2025-22010"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix soft lockup during bt pages loop\n\nDriver runs a for-loop when allocating bt pages and mapping them with\nbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,\nit may require a considerable loop count. This will lead to soft lockup:\n\n watchdog: BUG: soft lockup - CPU#27 stuck for 22s!\n ...\n Call trace:\n hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]\n hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]\n alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x118/0x290\n\n watchdog: BUG: soft lockup - CPU#35 stuck for 23s!\n ...\n Call trace:\n hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]\n mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]\n alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x120/0x2bc\n\nAdd a cond_resched() to fix soft lockup during these loops. In order not\nto affect the allocation performance of normal-size buffer, set the loop\ncount of a 100GB MR as the threshold to call cond_resched().",
"id": "GHSA-c2cr-w322-fppq",
"modified": "2025-11-03T21:33:30Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25655580136de59ec89f09089dd28008ea440fc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4104b0023ff66b5df900d23dbf38310893deca79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/461eb4ddede266df8f181f578732bb01742c3fd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/975355faba56c0751292ed15a90c3e2c7dc0aad6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ab20fec7a1ce3057ad86afd27bfd08420b7cd11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efe544462fc0b499725364f90bd0f8bbf16f861a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C34Q-8XRW-G745
Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-06-03 18:53In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix a nested dead lock as part of ODP flow
Fix a nested dead lock as part of ODP flow by using mmput_async().
From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex.
Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available.
[1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? process_one_work+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? set_kthread_struct+0x50/0x50 [64843.078085] ret_from_fork+0x22/0x30 [64843.078093]
{
"affected": [],
"aliases": [
"CVE-2022-48675"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T15:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/core: Fix a nested dead lock as part of ODP flow\n\nFix a nested dead lock as part of ODP flow by using mmput_async().\n\nFrom the below call trace [1] can see that calling mmput() once we have\nthe umem_odp-\u003eumem_mutex locked as required by\nib_umem_odp_map_dma_and_lock() might trigger in the same task the\nexit_mmap()-\u003e__mmu_notifier_release()-\u003emlx5_ib_invalidate_range() which\nmay dead lock when trying to lock the same mutex.\n\nMoving to use mmput_async() will solve the problem as the above\nexit_mmap() flow will be called in other task and will be executed once\nthe lock will be available.\n\n[1]\n[64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:\n2 flags:0x00004000\n[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]\n[64843.077719] Call Trace:\n[64843.077722] \u003cTASK\u003e\n[64843.077724] __schedule+0x23d/0x590\n[64843.077729] schedule+0x4e/0xb0\n[64843.077735] schedule_preempt_disabled+0xe/0x10\n[64843.077740] __mutex_lock.constprop.0+0x263/0x490\n[64843.077747] __mutex_lock_slowpath+0x13/0x20\n[64843.077752] mutex_lock+0x34/0x40\n[64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]\n[64843.077808] __mmu_notifier_release+0x1a4/0x200\n[64843.077816] exit_mmap+0x1bc/0x200\n[64843.077822] ? walk_page_range+0x9c/0x120\n[64843.077828] ? __cond_resched+0x1a/0x50\n[64843.077833] ? mutex_lock+0x13/0x40\n[64843.077839] ? uprobe_clear_state+0xac/0x120\n[64843.077860] mmput+0x5f/0x140\n[64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]\n[64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib]\n[64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib]\n[64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560\n[mlx5_ib]\n[64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]\n[64843.078051] process_one_work+0x22b/0x3d0\n[64843.078059] worker_thread+0x53/0x410\n[64843.078065] ? process_one_work+0x3d0/0x3d0\n[64843.078073] kthread+0x12a/0x150\n[64843.078079] ? set_kthread_struct+0x50/0x50\n[64843.078085] ret_from_fork+0x22/0x30\n[64843.078093] \u003c/TASK\u003e",
"id": "GHSA-c34q-8xrw-g745",
"modified": "2024-06-03T18:53:45Z",
"published": "2024-05-03T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48675"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C3J4-C39C-W5R2
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
smb/server: avoid deadlock when linking with ReplaceIfExists
If smb2_create_link() is called with ReplaceIfExists set and the name does exist then a deadlock will happen.
ksmbd_vfs_kern_path_locked() will return with success and the parent directory will be locked. ksmbd_vfs_remove_file() will then remove the file. ksmbd_vfs_link() will then be called while the parent is still locked. It will try to lock the same parent and will deadlock.
This patch moves the ksmbd_vfs_kern_path_unlock() call to before ksmbd_vfs_link() and then simplifies the code, removing the file_present flag variable.
{
"affected": [],
"aliases": [
"CVE-2025-38711"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-04T16:15:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: avoid deadlock when linking with ReplaceIfExists\n\nIf smb2_create_link() is called with ReplaceIfExists set and the name\ndoes exist then a deadlock will happen.\n\nksmbd_vfs_kern_path_locked() will return with success and the parent\ndirectory will be locked. ksmbd_vfs_remove_file() will then remove the\nfile. ksmbd_vfs_link() will then be called while the parent is still\nlocked. It will try to lock the same parent and will deadlock.\n\nThis patch moves the ksmbd_vfs_kern_path_unlock() call to *before*\nksmbd_vfs_link() and then simplifies the code, removing the file_present\nflag variable.",
"id": "GHSA-c3j4-c39c-w5r2",
"modified": "2026-05-12T15:31:01Z",
"published": "2025-09-05T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38711"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e858a7a51c7b8b009d8f246de7ceb7743b44a71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/814cfdb6358d9b84fcbec9918c8f938cc096a43a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5012ffe14120f978ee34aef4df3d6cb026b7c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a726fef6d7d4cfc365d3434e3916dbfe78991a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7dddd62578c2eb6cb28b8835556a121b5157323"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac98d54630d5b52e3f684d872f0d82c06c418ea9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5fc1400a34b4ea5e8f2ce296ea12bf8c8421694"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C4CJ-X9MV-WWGX
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
Coverity spotted that the cifs_sync_mid_result function could deadlock
"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"
Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
{
"affected": [],
"aliases": [
"CVE-2024-35998"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix lock ordering potential deadlock in cifs_sync_mid_result\n\nCoverity spotted that the cifs_sync_mid_result function could deadlock\n\n\"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires\nlock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock\"\n\nAddresses-Coverity: 1590401 (\"Thread deadlock (ORDER_REVERSAL)\")",
"id": "GHSA-c4cj-x9mv-wwgx",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35998"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C5CH-44Q8-865H
Vulnerability from github – Published: 2026-01-14 15:33 – Updated: 2026-03-25 21:30In the Linux kernel, the following vulnerability has been resolved:
block: Remove queue freezing from several sysfs store callbacks
Freezing the request queue from inside sysfs store callbacks may cause a deadlock in combination with the dm-multipath driver and the queue_if_no_path option. Additionally, freezing the request queue slows down system boot on systems where sysfs attributes are set synchronously.
Fix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue() calls from the store callbacks that do not strictly need these callbacks. Add the __data_racy annotation to request_queue.rq_timeout to suppress KCSAN data race reports about the rq_timeout reads.
This patch may cause a small delay in applying the new settings.
For all the attributes affected by this patch, I/O will complete correctly whether the old or the new value of the attribute is used.
This patch affects the following sysfs attributes: * io_poll_delay * io_timeout * nomerges * read_ahead_kb * rq_affinity
Here is an example of a deadlock triggered by running test srp/002 if this patch is not applied:
task:multipathd Call Trace: __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 schedule_preempt_disabled+0x1c/0x30 __mutex_lock+0xb89/0x1650 mutex_lock_nested+0x1f/0x30 dm_table_set_restrictions+0x823/0xdf0 __bind+0x166/0x590 dm_swap_table+0x2a7/0x490 do_resume+0x1b1/0x610 dev_suspend+0x55/0x1a0 ctl_ioctl+0x3a5/0x7e0 dm_ctl_ioctl+0x12/0x20 __x64_sys_ioctl+0x127/0x1a0 x64_sys_call+0xe2b/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 task:(udev-worker) Call Trace: __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 blk_mq_freeze_queue_wait+0xf2/0x140 blk_mq_freeze_queue_nomemsave+0x23/0x30 queue_ra_store+0x14e/0x290 queue_attr_store+0x23e/0x2c0 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3b2/0x630 vfs_write+0x4fd/0x1390 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x276/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
{
"affected": [],
"aliases": [
"CVE-2025-71117"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T15:16:01Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Remove queue freezing from several sysfs store callbacks\n\nFreezing the request queue from inside sysfs store callbacks may cause a\ndeadlock in combination with the dm-multipath driver and the\nqueue_if_no_path option. Additionally, freezing the request queue slows\ndown system boot on systems where sysfs attributes are set synchronously.\n\nFix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue()\ncalls from the store callbacks that do not strictly need these callbacks.\nAdd the __data_racy annotation to request_queue.rq_timeout to suppress\nKCSAN data race reports about the rq_timeout reads.\n\nThis patch may cause a small delay in applying the new settings.\n\nFor all the attributes affected by this patch, I/O will complete\ncorrectly whether the old or the new value of the attribute is used.\n\nThis patch affects the following sysfs attributes:\n* io_poll_delay\n* io_timeout\n* nomerges\n* read_ahead_kb\n* rq_affinity\n\nHere is an example of a deadlock triggered by running test srp/002\nif this patch is not applied:\n\ntask:multipathd\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x8c1/0x1bf0\n schedule+0xdd/0x270\n schedule_preempt_disabled+0x1c/0x30\n __mutex_lock+0xb89/0x1650\n mutex_lock_nested+0x1f/0x30\n dm_table_set_restrictions+0x823/0xdf0\n __bind+0x166/0x590\n dm_swap_table+0x2a7/0x490\n do_resume+0x1b1/0x610\n dev_suspend+0x55/0x1a0\n ctl_ioctl+0x3a5/0x7e0\n dm_ctl_ioctl+0x12/0x20\n __x64_sys_ioctl+0x127/0x1a0\n x64_sys_call+0xe2b/0x17d0\n do_syscall_64+0x96/0x3a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u003c/TASK\u003e\ntask:(udev-worker)\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x8c1/0x1bf0\n schedule+0xdd/0x270\n blk_mq_freeze_queue_wait+0xf2/0x140\n blk_mq_freeze_queue_nomemsave+0x23/0x30\n queue_ra_store+0x14e/0x290\n queue_attr_store+0x23e/0x2c0\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3b2/0x630\n vfs_write+0x4fd/0x1390\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x276/0x17d0\n do_syscall_64+0x96/0x3a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u003c/TASK\u003e",
"id": "GHSA-c5ch-44q8-865h",
"modified": "2026-03-25T21:30:22Z",
"published": "2026-01-14T15:33:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71117"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3997b3147c7b68b0308378fa95a766015f8ceb1c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/935a20d1bebf6236076785fac3ff81e3931834e9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C65J-9JMW-78H6
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-11-24 21:30In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293] Call Trace: call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0
Fix the problem by adding cond_resched() to raid10 like what raid1 did.
Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.
{
"affected": [],
"aliases": [
"CVE-2023-53151"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T14:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: prevent soft lockup while flush writes\n\nCurrently, there is no limit for raid1/raid10 plugged bio. While flushing\nwrites, raid1 has cond_resched() while raid10 doesn\u0027t, and too many\nwrites can cause soft lockup.\n\nFollow up soft lockup can be triggered easily with writeback test for\nraid10 with ramdisks:\n\nwatchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]\nCall Trace:\n \u003cTASK\u003e\n call_rcu+0x16/0x20\n put_object+0x41/0x80\n __delete_object+0x50/0x90\n delete_object_full+0x2b/0x40\n kmemleak_free+0x46/0xa0\n slab_free_freelist_hook.constprop.0+0xed/0x1a0\n kmem_cache_free+0xfd/0x300\n mempool_free_slab+0x1f/0x30\n mempool_free+0x3a/0x100\n bio_free+0x59/0x80\n bio_put+0xcf/0x2c0\n free_r10bio+0xbf/0xf0\n raid_end_bio_io+0x78/0xb0\n one_write_done+0x8a/0xa0\n raid10_end_write_request+0x1b4/0x430\n bio_endio+0x175/0x320\n brd_submit_bio+0x3b9/0x9b7 [brd]\n __submit_bio+0x69/0xe0\n submit_bio_noacct_nocheck+0x1e6/0x5a0\n submit_bio_noacct+0x38c/0x7e0\n flush_pending_writes+0xf0/0x240\n raid10d+0xac/0x1ed0\n\nFix the problem by adding cond_resched() to raid10 like what raid1 did.\n\nNote that unlimited plugged bio still need to be optimized, for example,\nin the case of lots of dirty pages writeback, this will take lots of\nmemory and io will spend a long time in plug, hence io latency is bad.",
"id": "GHSA-c65j-9jmw-78h6",
"modified": "2025-11-24T21:30:57Z",
"published": "2025-09-15T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/634daf6b2c81015cc5e28bf694a6a94a50c641cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84a578961b2566e475bfa8740beaf0abcc781a6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0345f7c7dbc5d42e4e6f1db99c1c1879d7b0eb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f45b2fa7678ab385299de345f7e85d05caea386b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fbf50184190d55f8717bd29aa9530c399be96f30"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
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-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.