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-CQH4-JV7G-JR53
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 18:33In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix runtime suspend deadlock when there is pending job
The runtime suspend callback drains the running job workqueue before suspending the device. If a job is still executing and calls pm_runtime_resume_and_get(), it can deadlock with the runtime suspend path.
Fix this by moving pm_runtime_resume_and_get() from the job execution routine to the job submission routine, ensuring the device is resumed before the job is queued and avoiding the deadlock during runtime suspend.
{
"affected": [],
"aliases": [
"CVE-2026-43446"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix runtime suspend deadlock when there is pending job\n\nThe runtime suspend callback drains the running job workqueue before\nsuspending the device. If a job is still executing and calls\npm_runtime_resume_and_get(), it can deadlock with the runtime suspend\npath.\n\nFix this by moving pm_runtime_resume_and_get() from the job execution\nroutine to the job submission routine, ensuring the device is resumed\nbefore the job is queued and avoiding the deadlock during runtime\nsuspend.",
"id": "GHSA-cqh4-jv7g-jr53",
"modified": "2026-05-21T18:33:06Z",
"published": "2026-05-08T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b13cb8f48a42ddf6dd98865b673a82e37ff238b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac72e7385a2c7533dd766de4197134d96230be85"
}
],
"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-CQJR-X55G-2J6V
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
gpio: rcar: Use raw_spinlock to protect register access
Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access.
[ 4.239592] =============================
[ 4.239595] [ BUG: Invalid wait context ]
[ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
[ 4.239603] -----------------------------
[ 4.239606] kworker/u8:5/76 is trying to lock:
[ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.239641] other info that might help us debug this:
[ 4.239643] context-{5:5}
[ 4.239646] 5 locks held by kworker/u8:5/76:
[ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c
[ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c
[ 4.254109] #2: ffff00000920c8f8
[ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.
[ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc
[ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690
[ 4.264840] #4:
[ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690
[ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
[ 4.304082] stack backtrace:
[ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35
[ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 4.304097] Workqueue: async async_run_entry_fn
[ 4.304106] Call trace:
[ 4.304110] show_stack+0x14/0x20 (C)
[ 4.304122] dump_stack_lvl+0x6c/0x90
[ 4.304131] dump_stack+0x14/0x1c
[ 4.304138] __lock_acquire+0xdfc/0x1584
[ 4.426274] lock_acquire+0x1c4/0x33c
[ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80
[ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8
[ 4.444422] __irq_set_trigger+0x5c/0x178
[ 4.448435] __setup_irq+0x2e4/0x690
[ 4.452012] request_threaded_irq+0xc4/0x190
[ 4.456285] devm_request_threaded_irq+0x7c/0xf4
[ 4.459398] ata1: link resume succeeded after 1 retries
[ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0
[ 4.470660] mmc_start_host+0x50/0xac
[ 4.474327] mmc_add_host+0x80/0xe4
[ 4.477817] tmio_mmc_host_probe+0x2b0/0x440
[ 4.482094] renesas_sdhi_probe+0x488/0x6f4
[ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78
[ 4.491509] platform_probe+0x64/0xd8
[ 4.495178] really_probe+0xb8/0x2a8
[ 4.498756] __driver_probe_device+0x74/0x118
[ 4.503116] driver_probe_device+0x3c/0x154
[ 4.507303] __device_attach_driver+0xd4/0x160
[ 4.511750] bus_for_each_drv+0x84/0xe0
[ 4.515588] __device_attach_async_helper+0xb0/0xdc
[ 4.520470] async_run_entry_fn+0x30/0xd8
[ 4.524481] process_one_work+0x210/0x62c
[ 4.528494] worker_thread+0x1ac/0x340
[ 4.532245] kthread+0x10c/0x110
[ 4.535476] ret_from_fork+0x10/0x20
{
"affected": [],
"aliases": [
"CVE-2025-21912"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: rcar: Use raw_spinlock to protect register access\n\nUse raw_spinlock in order to fix spurious messages about invalid context\nwhen spinlock debugging is enabled. The lock is only used to serialize\nregister access.\n\n [ 4.239592] =============================\n [ 4.239595] [ BUG: Invalid wait context ]\n [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted\n [ 4.239603] -----------------------------\n [ 4.239606] kworker/u8:5/76 is trying to lock:\n [ 4.239609] ffff0000091898a0 (\u0026p-\u003elock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164\n [ 4.239641] other info that might help us debug this:\n [ 4.239643] context-{5:5}\n [ 4.239646] 5 locks held by kworker/u8:5/76:\n [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c\n [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property \u0027frame-master\u0027 with a value.\n [ 4.254094] #1: ffff80008299bd80 ((work_completion)(\u0026entry-\u003ework)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c\n [ 4.254109] #2: ffff00000920c8f8\n [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property \u0027bitclock-master\u0027 with a value.\n [ 4.264803] (\u0026dev-\u003emutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc\n [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690\n [ 4.264840] #4:\n [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property \u0027frame-master\u0027 with a value.\n [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690\n [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz\n [ 4.304082] stack backtrace:\n [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35\n [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)\n [ 4.304097] Workqueue: async async_run_entry_fn\n [ 4.304106] Call trace:\n [ 4.304110] show_stack+0x14/0x20 (C)\n [ 4.304122] dump_stack_lvl+0x6c/0x90\n [ 4.304131] dump_stack+0x14/0x1c\n [ 4.304138] __lock_acquire+0xdfc/0x1584\n [ 4.426274] lock_acquire+0x1c4/0x33c\n [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80\n [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164\n [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8\n [ 4.444422] __irq_set_trigger+0x5c/0x178\n [ 4.448435] __setup_irq+0x2e4/0x690\n [ 4.452012] request_threaded_irq+0xc4/0x190\n [ 4.456285] devm_request_threaded_irq+0x7c/0xf4\n [ 4.459398] ata1: link resume succeeded after 1 retries\n [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0\n [ 4.470660] mmc_start_host+0x50/0xac\n [ 4.474327] mmc_add_host+0x80/0xe4\n [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440\n [ 4.482094] renesas_sdhi_probe+0x488/0x6f4\n [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78\n [ 4.491509] platform_probe+0x64/0xd8\n [ 4.495178] really_probe+0xb8/0x2a8\n [ 4.498756] __driver_probe_device+0x74/0x118\n [ 4.503116] driver_probe_device+0x3c/0x154\n [ 4.507303] __device_attach_driver+0xd4/0x160\n [ 4.511750] bus_for_each_drv+0x84/0xe0\n [ 4.515588] __device_attach_async_helper+0xb0/0xdc\n [ 4.520470] async_run_entry_fn+0x30/0xd8\n [ 4.524481] process_one_work+0x210/0x62c\n [ 4.528494] worker_thread+0x1ac/0x340\n [ 4.532245] kthread+0x10c/0x110\n [ 4.535476] ret_from_fork+0x10/0x20",
"id": "GHSA-cqjr-x55g-2j6v",
"modified": "2025-11-03T21:33:21Z",
"published": "2025-04-01T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21912"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/389891ac9f678baf68e13623ef1308493af4b074"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e300913c42041e81c5b17a970c4e078086ff2d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51ef3073493e2a25dced05fdd59dfb059e7e284d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c1f36f9c9aca507d317479a3d3388150ae40a87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b42c84f9e4ec5bc2885e7fd80c79ec0352f5d2af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c10365031f16514a29c812cd909085a6e4ea4b61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-CQWH-R98H-2279
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible deadlock between unlink and dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-31598"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:37Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -\u003e ip_alloc_sem):\nocfs2_unlink\n ocfs2_prepare_orphan_dir\n ocfs2_lookup_lock_orphan_dir\n inode_lock(orphan_dir_inode) \u003c- lock A\n __ocfs2_prepare_orphan_dir\n ocfs2_prepare_dir_for_insert\n ocfs2_extend_dir\n\t ocfs2_expand_inline_dir\n\t down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n\nLock Chain #1 (ip_alloc_sem -\u003e orphan dir inode_lock):\nocfs2_dio_end_io_write\n down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n ocfs2_del_inode_from_orphan()\n inode_lock(orphan_dir_inode) \u003c- Lock A\n\nDeadlock Scenario:\n CPU0 (unlink) CPU1 (dio_end_io_write)\n ------ ------\n inode_lock(orphan_dir_inode)\n down_write(ip_alloc_sem)\n down_write(ip_alloc_sem)\n inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan. So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.",
"id": "GHSA-cqwh-r98h-2279",
"modified": "2026-06-01T18:31:27Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31598"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/297d8d7bb6a2bf133d3a3636edbdf94101cbd719"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b884d52273c60c298bd570163e8053657bbaff6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32630dee18c6bb2175c8a865a474749492eaf19c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b80b5a838a32437f2cae0662578bac216a2c51a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93f35419eb84d58820040642cb6e7528fe4aba7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b02da26a992db0c0e2559acbda0fc48d4a2fd337"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc0fb5c7d54c78be43a536df0e20dee32adb27d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e049f7a9bd80b7319590789ea5e1c523d6339d91"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9fb1a7b635849322e1d7b7b6b26389778ec8e82"
}
],
"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"
}
]
}
GHSA-CR25-MCG8-CFVP
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix for a potential deadlock
This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);
Fix this by temporarily releasing the reset_mutex.
{
"affected": [],
"aliases": [
"CVE-2024-57807"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: megaraid_sas: Fix for a potential deadlock\n\nThis fixes a \u0027possible circular locking dependency detected\u0027 warning\n CPU0 CPU1\n ---- ----\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n\nFix this by temporarily releasing the reset_mutex.",
"id": "GHSA-cr25-mcg8-cfvp",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606"
},
{
"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-CR4C-WW97-FPHQ
Vulnerability from github – Published: 2024-03-15 21:30 – Updated: 2025-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit:
1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0].
2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like:
rq_lock(rq) -> -------------------------+
trace_sched_switch() -> |
bpf_prog_xyz() -> +-> deadlock
selinux_lockdown() -> |
audit_log_end() -> |
wake_up_interruptible() -> |
try_to_wake_up() -> |
rq_lock(rq) --------------+
What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like this:
allow : lockdown { };
However, this doesn't match with the 'current' task where the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in this example. httpd has literally zero relation to this tracing program, and it would be nonsensical having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this case needs to be against the entity that is installing the BPF program. For example, if bpftrace would generate a histogram of syscall counts by user space application:
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
bpftrace would then go and generate a BPF program from this internally. One way of doing it [for the sake of the example] could be to call bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,str}() helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here. The BPF program _explicitly initiated the lockdown check. The allow/deny policy belongs in the context of bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system like my_random_tracer not.
Therefore fix all three issues at the same time by taking a completely different approach for the security_locked_down() hook, that is, move the check into the program verification phase where we actually retrieve the BPF func proto. This also reliably gets the task (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several millions of times per second.
The check is then also in line with other security_locked_down() hooks in the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore access or module_sig_check() for module signatures just to pick f ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47128"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-15T21:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---",
"id": "GHSA-cr4c-ww97-fphq",
"modified": "2025-03-13T21:31:00Z",
"published": "2024-03-15T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47128"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc"
}
],
"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-CRW3-PH9V-P9P3
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix locking in pdc_iodc_print() firmware call
Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.
{
"affected": [],
"aliases": [
"CVE-2022-50518"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:35Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.",
"id": "GHSA-crw3-ph9v-p9p3",
"modified": "2026-02-04T18:30:19Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04a603058e70b8b881bb7860b8bd649f931f2591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/553bc5890ed96a8d006224c3a4673c47fee0d12a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7236aae5f81f3efbd93d0601e74fc05994bc2580"
}
],
"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-CRW5-QP92-P6M7
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2024-09-09 18:30In the Linux kernel, the following vulnerability has been resolved:
f2fs: don't set RO when shutting down f2fs
Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below.
f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread);
{
"affected": [],
"aliases": [
"CVE-2024-40969"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: don\u0027t set RO when shutting down f2fs\n\nShutdown does not check the error of thaw_super due to readonly, which\ncauses a deadlock like below.\n\nf2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread\n - bdev_freeze\n - freeze_super\n - f2fs_stop_checkpoint()\n - f2fs_handle_critical_error - sb_start_write\n - set RO - waiting\n - bdev_thaw\n - thaw_super_locked\n - return -EINVAL, if sb_rdonly()\n - f2fs_stop_discard_thread\n -\u003e wait for kthread_stop(discard_thread);",
"id": "GHSA-crw5-qp92-p6m7",
"modified": "2024-09-09T18:30:29Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563"
}
],
"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-CW78-Q654-793W
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Avoid use of GFP_KERNEL in atomic context
Using GFP_KERNEL in preemption disable context, causing below warning when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 [ 32.558707] preempt_count: 1, expected: 0 [ 32.562710] RCU nest depth: 0, expected: 0 [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7 [ 32.576188] Hardware name: Marvell CN106XX board (DT) [ 32.581232] Call trace: [ 32.583670] dump_backtrace.part.0+0xe0/0xf0 [ 32.587937] show_stack+0x18/0x30 [ 32.591245] dump_stack_lvl+0x68/0x84 [ 32.594900] dump_stack+0x18/0x34 [ 32.598206] __might_resched+0x12c/0x160 [ 32.602122] __might_sleep+0x48/0xa0 [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0 [ 32.610301] __kmalloc+0x58/0x190 [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314 [ 32.618134] otx2_open+0x1d4/0x9d0
To avoid use of GFP_ATOMIC for memory allocation, disable preemption after all memory allocation is done.
{
"affected": [],
"aliases": [
"CVE-2023-53030"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Avoid use of GFP_KERNEL in atomic context\n\nUsing GFP_KERNEL in preemption disable context, causing below warning\nwhen CONFIG_DEBUG_ATOMIC_SLEEP is enabled.\n\n[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274\n[ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n[ 32.558707] preempt_count: 1, expected: 0\n[ 32.562710] RCU nest depth: 0, expected: 0\n[ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7\n[ 32.576188] Hardware name: Marvell CN106XX board (DT)\n[ 32.581232] Call trace:\n[ 32.583670] dump_backtrace.part.0+0xe0/0xf0\n[ 32.587937] show_stack+0x18/0x30\n[ 32.591245] dump_stack_lvl+0x68/0x84\n[ 32.594900] dump_stack+0x18/0x34\n[ 32.598206] __might_resched+0x12c/0x160\n[ 32.602122] __might_sleep+0x48/0xa0\n[ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0\n[ 32.610301] __kmalloc+0x58/0x190\n[ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314\n[ 32.618134] otx2_open+0x1d4/0x9d0\n\nTo avoid use of GFP_ATOMIC for memory allocation, disable preemption\nafter all memory allocation is done.",
"id": "GHSA-cw78-q654-793w",
"modified": "2025-10-31T21:30:52Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1eb57b87f106c90cee6b2a56a10f2e29c7a25f3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2827c4eb429db64befdca11362e2b1c5f524f6ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87b93b678e95c7d93fe6a55b0e0fbda26d8c7760"
}
],
"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-CWR2-26GQ-V2XR
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.
{
"affected": [],
"aliases": [
"CVE-2024-26696"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix hang in nilfs_lookup_dirty_data_buffers()\n\nSyzbot reported a hang issue in migrate_pages_batch() called by mbind()\nand nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.\n\nWhile migrate_pages_batch() locks a folio and waits for the writeback to\ncomplete, the log writer thread that should bring the writeback to\ncompletion picks up the folio being written back in\nnilfs_lookup_dirty_data_buffers() that it calls for subsequent log\ncreation and was trying to lock the folio. Thus causing a deadlock.\n\nIn the first place, it is unexpected that folios/pages in the middle of\nwriteback will be updated and become dirty. Nilfs2 adds a checksum to\nverify the validity of the log being written and uses it for recovery at\nmount, so data changes during writeback are suppressed. Since this is\nbroken, an unclean shutdown could potentially cause recovery to fail.\n\nInvestigation revealed that the root cause is that the wait for writeback\ncompletion in nilfs_page_mkwrite() is conditional, and if the backing\ndevice does not require stable writes, data may be modified without\nwaiting.\n\nFix these issues by making nilfs_page_mkwrite() wait for writeback to\nfinish regardless of the stable write requirement of the backing device.",
"id": "GHSA-cwr2-26gq-v2xr",
"modified": "2025-03-17T18:31:38Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26696"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-CWWG-93GV-4R7H
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.
{
"affected": [],
"aliases": [
"CVE-2024-35806"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\n\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.",
"id": "GHSA-cwwg-93gv-4r7h",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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"
}
]
}
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.