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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-FXW3-5JMJ-82P9
Vulnerability from github – Published: 2025-10-22 18:30 – Updated: 2025-10-22 18:30In the Linux kernel, the following vulnerability has been resolved:
PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()
The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock:
sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0
Previously, pci_dev_lock() acquired the config space access lock before the device lock:
pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock
Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4).
Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path.
[bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
{
"affected": [],
"aliases": [
"CVE-2022-49434"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()\n\nThe sysfs sriov_numvfs_store() path acquires the device lock before the\nconfig space access lock:\n\n sriov_numvfs_store\n device_lock # A (1) acquire device lock\n sriov_configure\n vfio_pci_sriov_configure # (for example)\n vfio_pci_core_sriov_configure\n pci_disable_sriov\n sriov_disable\n pci_cfg_access_lock\n pci_wait_cfg # B (4) wait for dev-\u003eblock_cfg_access == 0\n\nPreviously, pci_dev_lock() acquired the config space access lock before the\ndevice lock:\n\n pci_dev_lock\n pci_cfg_access_lock\n dev-\u003eblock_cfg_access = 1 # B (2) set dev-\u003eblock_cfg_access = 1\n device_lock # A (3) wait for device lock\n\nAny path that uses pci_dev_lock(), e.g., pci_reset_function(), may\ndeadlock with sriov_numvfs_store() if the operations occur in the sequence\n(1) (2) (3) (4).\n\nAvoid the deadlock by reversing the order in pci_dev_lock() so it acquires\nthe device lock before the config space access lock, the same as the\nsriov_numvfs_store() path.\n\n[bhelgaas: combined and adapted commit log from Jay Zhou\u0027s independent\nsubsequent posting:\nhttps://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]",
"id": "GHSA-fxw3-5jmj-82p9",
"modified": "2025-10-22T18:30:31Z",
"published": "2025-10-22T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49434"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da9792920ab525b8a932aa9aeee34529ad7b83f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e"
}
],
"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-G29R-CH4V-Q6CX
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().
{
"affected": [],
"aliases": [
"CVE-2024-47143"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0027t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0027s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0027s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().",
"id": "GHSA-g29r-ch4v-q6cx",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7543c3e3b9b88212fcd0aaf5cab5588797bdc7de"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c1b4fea8d62285f5e1a8194889b39661608bd8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c212d91070beca0d03fef7bf988baf4ff4b3eee4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efe1b9bbf356357fdff0399af361133d6e3ba18e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2b95248a16c5186d1c658fc0aeb2f3bd95e5259"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-G2G9-6HGR-7F52
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio
Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem.
Warning will be produced if folio is not locked during unmap:
------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
{
"affected": [],
"aliases": [
"CVE-2025-21931"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio\n\nCommit b15c87263a69 (\"hwpoison, memory_hotplug: allow hwpoisoned pages to\nbe offlined) add page poison checks in do_migrate_range in order to make\noffline hwpoisoned page possible by introducing isolate_lru_page and\ntry_to_unmap for hwpoisoned page. However folio lock must be held before\ncalling try_to_unmap. Add it to fix this problem.\n\nWarning will be produced if folio is not locked during unmap:\n\n ------------[ cut here ]------------\n kernel BUG at ./include/linux/swapops.h:400!\n Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n Modules linked in:\n CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41\n Tainted: [W]=WARN\n Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : try_to_unmap_one+0xb08/0xd3c\n lr : try_to_unmap_one+0x3dc/0xd3c\n Call trace:\n try_to_unmap_one+0xb08/0xd3c (P)\n try_to_unmap_one+0x3dc/0xd3c (L)\n rmap_walk_anon+0xdc/0x1f8\n rmap_walk+0x3c/0x58\n try_to_unmap+0x88/0x90\n unmap_poisoned_folio+0x30/0xa8\n do_migrate_range+0x4a0/0x568\n offline_pages+0x5a4/0x670\n memory_block_action+0x17c/0x374\n memory_subsys_offline+0x3c/0x78\n device_offline+0xa4/0xd0\n state_store+0x8c/0xf0\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x44/0x54\n kernfs_fop_write_iter+0x118/0x1a8\n vfs_write+0x3a8/0x4bc\n ksys_write+0x6c/0xf8\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x44/0x100\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xd0\n el0t_64_sync_handler+0xc8/0xcc\n el0t_64_sync+0x198/0x19c\n Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)\n ---[ end trace 0000000000000000 ]---",
"id": "GHSA-g2g9-6hgr-7f52",
"modified": "2025-11-03T21:33:24Z",
"published": "2025-04-01T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21931"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3926b572fd073491bde13ec42ee08ac1b337bf4d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/576a2f4c437c19bec7d05d05b5990f178d2b0f40"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/629dfc6ba5431056701d4e44830f3409b989955a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93df6da64b004f75d307ed08d3f0f1020280d339"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af288a426c3e3552b62595c6138ec6371a17dbba"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.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-G2QX-6GHW-67HM
Vulnerability from github – Published: 2022-02-15 00:33 – Updated: 2021-05-20 22:20An issue was discovered in Gitea in which an attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-gitea/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13246"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T22:20:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "An issue was discovered in Gitea in which an attacker can trigger a deadlock by initiating a transfer of a repository\u0027s ownership from one organization to another.",
"id": "GHSA-g2qx-6ghw-67hm",
"modified": "2021-05-20T22:20:34Z",
"published": "2022-02-15T00:33:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13246"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/issues/10549"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/11438"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=DmVgADSVS88"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of Service in Gitea"
}
GHSA-G477-G2GM-CJMF
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-03-07 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix deadlock during RTC update
There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.
Here is deadlock backtrace:
kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff __switch_to+0x1a8/0x2d4 __schedule+0x684/0xa98 schedule+0x48/0xc8 schedule_timeout+0x48/0x170 do_wait_for_common+0x108/0x1b0 wait_for_completion+0x44/0x60 __flush_work+0x39c/0x424 __cancel_work_sync+0xd8/0x208 cancel_delayed_work_sync+0x14/0x28 __ufshcd_wl_suspend+0x19c/0x480 ufshcd_wl_runtime_suspend+0x3c/0x1d4 scsi_runtime_suspend+0x78/0xc8 __rpm_callback+0x94/0x3e0 rpm_suspend+0x2d4/0x65c __pm_runtime_suspend+0x80/0x114 scsi_runtime_idle+0x38/0x6c rpm_idle+0x264/0x338 __pm_runtime_idle+0x80/0x110 ufshcd_rtc_work+0x128/0x1e4 process_one_work+0x26c/0x650 worker_thread+0x260/0x3d8 kthread+0x110/0x134 ret_from_fork+0x10/0x20
Skip updating RTC if RPM state is not RPM_ACTIVE.
{
"affected": [],
"aliases": [
"CVE-2024-44953"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix deadlock during RTC update\n\nThere is a deadlock when runtime suspend waits for the flush of RTC work,\nand the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.\n\nHere is deadlock backtrace:\n\nkworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367\nptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff\n\u003cffffffee5e71ddb0\u003e __switch_to+0x1a8/0x2d4\n\u003cffffffee5e71e604\u003e __schedule+0x684/0xa98\n\u003cffffffee5e71ea60\u003e schedule+0x48/0xc8\n\u003cffffffee5e725f78\u003e schedule_timeout+0x48/0x170\n\u003cffffffee5e71fb74\u003e do_wait_for_common+0x108/0x1b0\n\u003cffffffee5e71efe0\u003e wait_for_completion+0x44/0x60\n\u003cffffffee5d6de968\u003e __flush_work+0x39c/0x424\n\u003cffffffee5d6decc0\u003e __cancel_work_sync+0xd8/0x208\n\u003cffffffee5d6dee2c\u003e cancel_delayed_work_sync+0x14/0x28\n\u003cffffffee5e2551b8\u003e __ufshcd_wl_suspend+0x19c/0x480\n\u003cffffffee5e255fb8\u003e ufshcd_wl_runtime_suspend+0x3c/0x1d4\n\u003cffffffee5dffd80c\u003e scsi_runtime_suspend+0x78/0xc8\n\u003cffffffee5df93580\u003e __rpm_callback+0x94/0x3e0\n\u003cffffffee5df90b0c\u003e rpm_suspend+0x2d4/0x65c\n\u003cffffffee5df91448\u003e __pm_runtime_suspend+0x80/0x114\n\u003cffffffee5dffd95c\u003e scsi_runtime_idle+0x38/0x6c\n\u003cffffffee5df912f4\u003e rpm_idle+0x264/0x338\n\u003cffffffee5df90f14\u003e __pm_runtime_idle+0x80/0x110\n\u003cffffffee5e24ce44\u003e ufshcd_rtc_work+0x128/0x1e4\n\u003cffffffee5d6e3a40\u003e process_one_work+0x26c/0x650\n\u003cffffffee5d6e65c8\u003e worker_thread+0x260/0x3d8\n\u003cffffffee5d6edec8\u003e kthread+0x110/0x134\n\u003cffffffee5d616b18\u003e ret_from_fork+0x10/0x20\n\nSkip updating RTC if RPM state is not RPM_ACTIVE.",
"id": "GHSA-g477-g2gm-cjmf",
"modified": "2025-03-07T18:31:00Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44953"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3911af778f208e5f49d43ce739332b91e26bc48e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4921b76bc9421d3838e167f6a17ea3112d8fe62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f13f1858a28c68b7fc0d72c2008d5c1f80d2e8d5"
}
],
"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-G4HW-WV9W-W499
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-26 21:30In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: add lock to protect parameter num_rdy
Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.
kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&]
kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
{
"affected": [],
"aliases": [
"CVE-2023-53519"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report\u0026]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report\u0026]\n\nkworker/u16:3: [name:report\u0026]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:\u00a0 v4l2_m2m_buf_queue+0xd8/0x10c",
"id": "GHSA-g4hw-wv9w-w499",
"modified": "2026-01-26T21:30:30Z",
"published": "2025-10-01T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53519"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fc7f87725805197388ba749a1801df33000fa50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c71aa5f1cf961264690f2560503ea396b6e3c680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e52de26cb37459b16213438a2c82feb155dd3bbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef009fe2010ea2a3a7045ecb72729cf366e0967b"
}
],
"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-G55P-876W-V4VX
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-09-24 18:30In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x2b2/0x440 queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ? __schedule+0x369/0xb40 ? __pfx_irq_thread_fn+0x10/0x10 ? irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ? preempt_count_add+0x74/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
The current implementation uses a spinlock to protect event log workqueue and will lead to the Call Trace due to potential task rescheduling.
To address the locking issue, convert the spinlock to mutex, allowing the drain_workqueue() to be called in a safe mutex-locked context.
This change ensures proper synchronization when accessing the event log workqueue, preventing potential Call Trace and improving the overall robustness of the code.
{
"affected": [],
"aliases": [
"CVE-2024-35991"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Convert spinlock to mutex to lock evl workqueue\n\ndrain_workqueue() cannot be called safely in a spinlocked context due to\npossible task rescheduling. In the multi-task scenario, calling\nqueue_work() while drain_workqueue() will lead to a Call Trace as\npushing a work on a draining workqueue is not permitted in spinlocked\ncontext.\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0x7d/0x140\n ? __queue_work+0x2b2/0x440\n ? report_bug+0x1f8/0x200\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __queue_work+0x2b2/0x440\n queue_work_on+0x28/0x30\n idxd_misc_thread+0x303/0x5a0 [idxd]\n ? __schedule+0x369/0xb40\n ? __pfx_irq_thread_fn+0x10/0x10\n ? irq_thread+0xbc/0x1b0\n irq_thread_fn+0x21/0x70\n irq_thread+0x102/0x1b0\n ? preempt_count_add+0x74/0xa0\n ? __pfx_irq_thread_dtor+0x10/0x10\n ? __pfx_irq_thread+0x10/0x10\n kthread+0x103/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nThe current implementation uses a spinlock to protect event log workqueue\nand will lead to the Call Trace due to potential task rescheduling.\n\nTo address the locking issue, convert the spinlock to mutex, allowing\nthe drain_workqueue() to be called in a safe mutex-locked context.\n\nThis change ensures proper synchronization when accessing the event log\nworkqueue, preventing potential Call Trace and improving the overall\nrobustness of the code.",
"id": "GHSA-g55p-876w-v4vx",
"modified": "2025-09-24T18:30:22Z",
"published": "2024-05-20T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44"
}
],
"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-G6F8-F8F2-6WH5
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock
A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice.
v2: - Modified the title and commit message
============================================ WARNING: possible recursive locking detected 6.11.0-mainline
init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock
but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&i3cbus->lock); lock(&i3cbus->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac
{
"affected": [],
"aliases": [
"CVE-2024-43098"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: Use i3cdev-\u003edesc-\u003einfo instead of calling i3c_device_get_info() to avoid deadlock\n\nA deadlock may happen since the i3c_master_register() acquires\n\u0026i3cbus-\u003elock twice. See the log below.\nUse i3cdev-\u003edesc-\u003einfo instead of calling i3c_device_info() to\navoid acquiring the lock twice.\n\nv2:\n - Modified the title and commit message\n\n============================================\nWARNING: possible recursive locking detected\n6.11.0-mainline\n--------------------------------------------\ninit/1 is trying to acquire lock:\nf1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_bus_normaluse_lock\n\nbut task is already holding lock:\nf1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_master_register\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026i3cbus-\u003elock);\n lock(\u0026i3cbus-\u003elock);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n2 locks held by init/1:\n #0: fcffff809b6798f8 (\u0026dev-\u003emutex){....}-{3:3}, at: __driver_attach\n #1: f1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_master_register\n\nstack backtrace:\nCPU: 6 UID: 0 PID: 1 Comm: init\nCall trace:\n dump_backtrace+0xfc/0x17c\n show_stack+0x18/0x28\n dump_stack_lvl+0x40/0xc0\n dump_stack+0x18/0x24\n print_deadlock_bug+0x388/0x390\n __lock_acquire+0x18bc/0x32ec\n lock_acquire+0x134/0x2b0\n down_read+0x50/0x19c\n i3c_bus_normaluse_lock+0x14/0x24\n i3c_device_get_info+0x24/0x58\n i3c_device_uevent+0x34/0xa4\n dev_uevent+0x310/0x384\n kobject_uevent_env+0x244/0x414\n kobject_uevent+0x14/0x20\n device_add+0x278/0x460\n device_register+0x20/0x34\n i3c_master_register_new_i3c_devs+0x78/0x154\n i3c_master_register+0x6a0/0x6d4\n mtk_i3c_master_probe+0x3b8/0x4d8\n platform_probe+0xa0/0xe0\n really_probe+0x114/0x454\n __driver_probe_device+0xa0/0x15c\n driver_probe_device+0x3c/0x1ac\n __driver_attach+0xc4/0x1f0\n bus_for_each_dev+0x104/0x160\n driver_attach+0x24/0x34\n bus_add_driver+0x14c/0x294\n driver_register+0x68/0x104\n __platform_driver_register+0x20/0x30\n init_module+0x20/0xfe4\n do_one_initcall+0x184/0x464\n do_init_module+0x58/0x1ec\n load_module+0xefc/0x10c8\n __arm64_sys_finit_module+0x238/0x33c\n invoke_syscall+0x58/0x10c\n el0_svc_common+0xa8/0xdc\n do_el0_svc+0x1c/0x28\n el0_svc+0x50/0xac\n el0t_64_sync_handler+0x70/0xbc\n el0t_64_sync+0x1a8/0x1ac",
"id": "GHSA-g6f8-f8f2-6wh5",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f51ae217d09c361ede900b94735a6d2df6c0344"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d98fa2a50b8058de52ada168fa5dbabb574711b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ac1dd51aaa0ce8b5421d1137e857955a4b6f55e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cf7b65f7029914dc0cd7db86fac9ee5159008c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/816187b1833908941286e71b0041059a4acd52ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a2173660ee53d5699744f02e6ab7bf89fcd0b1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffe19e363c6f8b992ba835a361542568dea17409"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-G6HH-758M-XQ4Q
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-05-29 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix dead lock for suspend and resume
When an application issues a query IOCTL while auto suspend is running, a deadlock can occur. The query path holds dev_lock and then calls pm_runtime_resume_and_get(), which waits for the ongoing suspend to complete. Meanwhile, the suspend callback attempts to acquire dev_lock and blocks, resulting in a deadlock.
Fix this by releasing dev_lock before calling pm_runtime_resume_and_get() and reacquiring it after the call completes. Also acquire dev_lock in the resume callback to keep the locking consistent.
{
"affected": [],
"aliases": [
"CVE-2026-23295"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix dead lock for suspend and resume\n\nWhen an application issues a query IOCTL while auto suspend is running,\na deadlock can occur. The query path holds dev_lock and then calls\npm_runtime_resume_and_get(), which waits for the ongoing suspend to\ncomplete. Meanwhile, the suspend callback attempts to acquire dev_lock\nand blocks, resulting in a deadlock.\n\nFix this by releasing dev_lock before calling pm_runtime_resume_and_get()\nand reacquiring it after the call completes. Also acquire dev_lock in the\nresume callback to keep the locking consistent.",
"id": "GHSA-g6hh-758m-xq4q",
"modified": "2026-05-29T15:30:26Z",
"published": "2026-03-25T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23295"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1aa82181a3c285c7351523d587f7981ae4c015c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac24537478dd8eb2fd3984b4652bb19461e5e74c"
}
],
"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-G72F-6G67-W739
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-18 15:30In the Linux kernel, the following vulnerability has been resolved:
iavf: get rid of the crit lock
Get rid of the crit lock. That frees us from the error prone logic of try_locks.
Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case.
Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks.
Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock).
Extend protected part of iavf_watchdog_task() to include scheduling more work.
Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now.
[splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock.
[splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock.
[1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
{
"affected": [],
"aliases": [
"CVE-2025-38311"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T08:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: get rid of the crit lock\n\nGet rid of the crit lock.\nThat frees us from the error prone logic of try_locks.\n\nThanks to netdev_lock() by Jakub it is now easy, and in most cases we were\nprotected by it already - replace crit lock by netdev lock when it was not\nthe case.\n\nLockdep reports that we should cancel the work under crit_lock [splat1],\nand that was the scheme we have mostly followed since [1] by Slawomir.\nBut when that is done we still got into deadlocks [splat2]. So instead\nwe should look at the bigger problem, namely \"weird locking/scheduling\"\nof the iavf. The first step to fix that is to remove the crit lock.\nI will followup with a -next series that simplifies scheduling/tasks.\n\nCancel the work without netdev lock (weird unlock+lock scheme),\nto fix the [splat2] (which would be totally ugly if we would kept\nthe crit lock).\n\nExtend protected part of iavf_watchdog_task() to include scheduling\nmore work.\n\nNote that the removed comment in iavf_reset_task() was misplaced,\nit belonged to inside of the removed if condition, so it\u0027s gone now.\n\n[splat1] - w/o this patch - The deadlock during VF removal:\n WARNING: possible circular locking dependency detected\n sh/3825 is trying to acquire lock:\n ((work_completion)(\u0026(\u0026adapter-\u003ewatchdog_task)-\u003ework)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470\n but task is already holding lock:\n (\u0026adapter-\u003ecrit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]\n which lock already depends on the new lock.\n\n[splat2] - when cancelling work under crit lock, w/o this series,\n\t see [2] for the band aid attempt\n WARNING: possible circular locking dependency detected\n sh/3550 is trying to acquire lock:\n ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n but task is already holding lock:\n (\u0026dev-\u003elock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]\n which lock already depends on the new lock.\n\n[1] fc2e6b3b132a (\"iavf: Rework mutexes for better synchronisation\")\n[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a",
"id": "GHSA-g72f-6g67-w739",
"modified": "2025-11-18T15:30:40Z",
"published": "2025-07-10T09:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38311"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8"
}
],
"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.