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.
713 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-C6P9-MW2R-7MC4
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
cfg80211: fix management registrations locking
The management registrations locking was broken, the list was locked for each wdev, but cfg80211_mgmt_registrations_update() iterated it without holding all the correct spinlocks, causing list corruption.
Rather than trying to fix it with fine-grained locking, just move the lock to the wiphy/rdev (still need the list on each wdev), we already need to hold the wdev lock to change it, so there's no contention on the lock in any case. This trivially fixes the bug since we hold one wdev's lock already, and now will hold the lock that protects all lists.
{
"affected": [],
"aliases": [
"CVE-2021-47494"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T09:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncfg80211: fix management registrations locking\n\nThe management registrations locking was broken, the list was\nlocked for each wdev, but cfg80211_mgmt_registrations_update()\niterated it without holding all the correct spinlocks, causing\nlist corruption.\n\nRather than trying to fix it with fine-grained locking, just\nmove the lock to the wiphy/rdev (still need the list on each\nwdev), we already need to hold the wdev lock to change it, so\nthere\u0027s no contention on the lock in any case. This trivially\nfixes the bug since we hold one wdev\u0027s lock already, and now\nwill hold the lock that protects all lists.",
"id": "GHSA-c6p9-mw2r-7mc4",
"modified": "2025-09-24T21:30:30Z",
"published": "2024-05-22T09:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47494"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09b1d5dc6ce1c9151777f6c4e128a59457704c97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c897f39b71fe68f90599f6a45b5f7bf5618420e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c22227e39c7a0b4dab55617ee8d34d171fab8d4"
}
],
"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-C6Q3-XGG3-276C
Vulnerability from github – Published: 2024-03-04 18:30 – Updated: 2025-02-03 15:31In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix locking in ieee80211_start_ap error path
We need to hold the local->mtx to release the channel context, as even encoded by the lockdep_assert_held() there. Fix it.
{
"affected": [],
"aliases": [
"CVE-2021-47091"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-04T18:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix locking in ieee80211_start_ap error path\n\nWe need to hold the local-\u003emtx to release the channel context,\nas even encoded by the lockdep_assert_held() there. Fix it.",
"id": "GHSA-c6q3-xgg3-276c",
"modified": "2025-02-03T15:31:59Z",
"published": "2024-03-04T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47091"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87a270625a89fc841f1a7e21aae6176543d8385c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac61b9c6c0549aaeb98194cf429d93c41bfe5f79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1d1ec4db5f7264cfc21993e59e8f2dcecf4b44f"
}
],
"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-C7GR-CRGH-PWCP
Vulnerability from github – Published: 2025-03-17 18:31 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
tty: fix deadlock caused by calling printk() under tty_port->lock
pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided.
Syzbot reported the following lockdep error:
====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]
-> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49441"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix deadlock caused by calling printk() under tty_port-\u003elock\n\npty_write() invokes kmalloc() which may invoke a normal printk() to print\nfailure message. This can cause a deadlock in the scenario reported by\nsyz-bot below:\n\n CPU0 CPU1 CPU2\n ---- ---- ----\n lock(console_owner);\n lock(\u0026port_lock_key);\n lock(\u0026port-\u003elock);\n lock(\u0026port_lock_key);\n lock(\u0026port-\u003elock);\n lock(console_owner);\n\nAs commit dbdda842fe96 (\"printk: Add console owner and waiter logic to\nload balance console writes\") said, such deadlock can be prevented by\nusing printk_deferred() in kmalloc() (which is invoked in the section\nguarded by the port-\u003elock). But there are too many printk() on the\nkmalloc() path, and kmalloc() can be called from anywhere, so changing\nprintk() to printk_deferred() is too complicated and inelegant.\n\nTherefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so\nthat printk() will not be called, and this deadlock problem can be\navoided.\n\nSyzbot reported the following lockdep error:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.4.143-00237-g08ccc19a-dirty #10 Not tainted\n------------------------------------------------------\nsyz-executor.4/29420 is trying to acquire lock:\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023\n\nbut task is already holding lock:\nffff8880119c9158 (\u0026port-\u003elock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (\u0026port-\u003elock){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n tty_port_tty_get drivers/tty/tty_port.c:288 [inline] \t\t\u003c-- lock(\u0026port-\u003elock);\n tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47\n serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767\n serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854\n serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] \t\u003c-- lock(\u0026port_lock_key);\n serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870\n serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126\n __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156\n [...]\n\n-\u003e #1 (\u0026port_lock_key){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198\n\t\t\t\t\t\t\t\t\t\t\u003c-- lock(\u0026port_lock_key);\n call_console_drivers kernel/printk/printk.c:1819 [inline]\n console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504\n vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024\t\t\t\u003c-- lock(console_owner);\n vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394\n printk+0xba/0xed kernel/printk/printk.c:2084\n register_console+0x8b3/0xc10 kernel/printk/printk.c:2829\n univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681\n console_init+0x49d/0x6d3 kernel/printk/printk.c:2915\n start_kernel+0x5e9/0x879 init/main.c:713\n secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241\n\n-\u003e #0 (console_owner){....}-{0:0}:\n [...]\n lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734\n console_trylock_spinning kernel/printk/printk.c:1773 \n---truncated---",
"id": "GHSA-c7gr-crgh-pwcp",
"modified": "2025-03-17T18:31:47Z",
"published": "2025-03-17T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49441"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6"
}
],
"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.