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-PF8W-93QV-JM8P
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2025-11-25 21:32In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix lockdep warning during rmmod
The commit under the Fixes tag added a netdev_assert_locked() in bnxt_free_ntp_fltrs(). The lock should be held during normal run-time but the assert will be triggered (see below) during bnxt_remove_one() which should not need the lock. The netdev is already unregistered by then. Fix it by calling netdev_assert_locked_or_invisible() which will not assert if the netdev is unregistered.
WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re] CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa92082387da0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001 RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3 R10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001 R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100 FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0 Call Trace: bnxt_remove_one+0x57/0x180 [bnxt_en] pci_device_remove+0x39/0xc0 device_release_driver_internal+0xa5/0x130 driver_detach+0x42/0x90 bus_remove_driver+0x61/0xc0 pci_unregister_driver+0x38/0x90 bnxt_exit+0xc/0x7d0 [bnxt_en]
{
"affected": [],
"aliases": [
"CVE-2025-39769"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix lockdep warning during rmmod\n\nThe commit under the Fixes tag added a netdev_assert_locked() in\nbnxt_free_ntp_fltrs(). The lock should be held during normal run-time\nbut the assert will be triggered (see below) during bnxt_remove_one()\nwhich should not need the lock. The netdev is already unregistered by\nthen. Fix it by calling netdev_assert_locked_or_invisible() which will\nnot assert if the netdev is unregistered.\n\nWARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]\nModules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re]\nCPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary)\nTainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\nHardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\nRIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]\nCode: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff \u003c0f\u003e 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffa92082387da0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001\nRDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf\nRBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3\nR10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001\nR13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100\nFS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0\nCall Trace:\n \u003cTASK\u003e\n bnxt_remove_one+0x57/0x180 [bnxt_en]\n pci_device_remove+0x39/0xc0\n device_release_driver_internal+0xa5/0x130\n driver_detach+0x42/0x90\n bus_remove_driver+0x61/0xc0\n pci_unregister_driver+0x38/0x90\n bnxt_exit+0xc/0x7d0 [bnxt_en]",
"id": "GHSA-pf8w-93qv-jm8p",
"modified": "2025-11-25T21:32:04Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39769"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4611d88a37cfc18cbabc6978aaf7325d1ae3f53a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5885d39dce879fbbc953f40e19adb60c29802302"
}
],
"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-PFF6-G7WW-P3V3
Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-04-24 15:32In the Linux kernel, the following vulnerability has been resolved:
rust_binder: call set_notification_done() without proc lock
Consider the following sequence of events on a death listener: 1. The remote process dies and sends a BR_DEAD_BINDER message. 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command. 3. The local process then invokes the BC_DEAD_BINDER_DONE. Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().
However, this can result in a deadlock if the current thread is not a looper. This is because dead_binder_done() still holds the proc lock during set_notification_done(), which called push_work_if_looper(). Normally, push_work_if_looper() takes the thread lock, which is fine to take under the proc lock. But if the current thread is not a looper, then it falls back to delivering the reply to the process work queue, which involves taking the proc lock. Since the proc lock is already held, this is a deadlock.
Fix this by releasing the proc lock during set_notification_done(). It was not intentional that it was held during that function to begin with.
I don't think this ever happens in Android because BC_DEAD_BINDER_DONE is only invoked in response to BR_DEAD_BINDER messages, and the kernel always delivers BR_DEAD_BINDER to a looper. So there's no scenario where Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.
{
"affected": [],
"aliases": [
"CVE-2026-23400"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-29T13:16:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: call set_notification_done() without proc lock\n\nConsider the following sequence of events on a death listener:\n1. The remote process dies and sends a BR_DEAD_BINDER message.\n2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.\n3. The local process then invokes the BC_DEAD_BINDER_DONE.\nThen, the kernel will reply to the BC_DEAD_BINDER_DONE command with a\nBR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().\n\nHowever, this can result in a deadlock if the current thread is not a\nlooper. This is because dead_binder_done() still holds the proc lock\nduring set_notification_done(), which called push_work_if_looper().\nNormally, push_work_if_looper() takes the thread lock, which is fine to\ntake under the proc lock. But if the current thread is not a looper,\nthen it falls back to delivering the reply to the process work queue,\nwhich involves taking the proc lock. Since the proc lock is already\nheld, this is a deadlock.\n\nFix this by releasing the proc lock during set_notification_done(). It\nwas not intentional that it was held during that function to begin with.\n\nI don\u0027t think this ever happens in Android because BC_DEAD_BINDER_DONE\nis only invoked in response to BR_DEAD_BINDER messages, and the kernel\nalways delivers BR_DEAD_BINDER to a looper. So there\u0027s no scenario where\nAndroid userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.",
"id": "GHSA-pff6-g7ww-p3v3",
"modified": "2026-04-24T15:32:19Z",
"published": "2026-03-29T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e303f0febb65a434040774b793ba8356698802b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3be72099067d2cd4a0e089696f19780f75b2b88a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd109e3442817bc03ad1f3ffd541092f8c428141"
}
],
"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-PGJM-RQQP-M93M
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()
The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.
{
"affected": [],
"aliases": [
"CVE-2025-21820"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: xilinx_uartps: split sysrq handling\n\nlockdep detects the following circular locking dependency:\n\nCPU 0 CPU 1\n========================== ============================\ncdns_uart_isr() printk()\n uart_port_lock(port) console_lock()\n\t\t\t cdns_uart_console_write()\n if (!port-\u003esysrq)\n uart_port_lock(port)\n uart_handle_break()\n port-\u003esysrq = ...\n uart_handle_sysrq_char()\n printk()\n console_lock()\n\nThe fixed commit attempts to avoid this situation by only taking the\nport lock in cdns_uart_console_write if port-\u003esysrq unset. However, if\n(as shown above) cdns_uart_console_write runs before port-\u003esysrq is set,\nthen it will try to take the port lock anyway. This may result in a\ndeadlock.\n\nFix this by splitting sysrq handling into two parts. We use the prepare\nhelper under the port lock and defer handling until we release the lock.",
"id": "GHSA-pgjm-rqqp-m93m",
"modified": "2025-11-03T21:33:02Z",
"published": "2025-02-27T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4410dba9807a17a93f649a9f5870ceaf30a675a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ea0e7b3d7b8f2f0fc9db491ff22a0abe120801c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b88a7c4584ba67267a051069b8abe44fc9595b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b06f388994500297bb91be60ffaf6825ecfd2afe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de5bd24197bd9ee37ec1e379a3d882bbd15c5065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e22a97700901ba5e8bf8db68056a0d50f9440cae"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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-PH47-5XQG-MR4X
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645149; Issue ID: ALPS07645167.
{
"affected": [],
"aliases": [
"CVE-2023-20737"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:13Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645149; Issue ID: ALPS07645167.",
"id": "GHSA-ph47-5xqg-mr4x",
"modified": "2024-04-04T04:35:26Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20737"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PH55-5XQF-59R7
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2025-01-14 15:30In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
{
"affected": [],
"aliases": [
"CVE-2023-52486"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Don\u0027t unref the same fb many times by mistake due to deadlock handling\n\nIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()\nwe proceed to unref the fb and then retry the whole thing from the top.\nBut we forget to reset the fb pointer back to NULL, and so if we then\nget another error during the retry, before the fb lookup, we proceed\nthe unref the same fb again without having gotten another reference.\nThe end result is that the fb will (eventually) end up being freed\nwhile it\u0027s still in use.\n\nReset fb to NULL once we\u0027ve unreffed it to avoid doing it again\nuntil we\u0027ve done another fb lookup.\n\nThis turned out to be pretty easy to hit on a DG2 when doing async\nflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I\nsaw that drm_closefb() simply got stuck in a busy loop while walking\nthe framebuffer list. Fortunately I was able to convince it to oops\ninstead, and from there it was easier to track down the culprit.",
"id": "GHSA-ph55-5xqf-59r7",
"modified": "2025-01-14T15:30:47Z",
"published": "2024-03-11T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52486"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105"
},
{
"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-PH5R-C8GC-XG6F
Vulnerability from github – Published: 2024-03-21 12:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout").
Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.
According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.
{
"affected": [],
"aliases": [
"CVE-2024-26643"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-21T11:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\n\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\n\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set\nelement timeout\").\n\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\n\nAccording to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on\ntransaction abort\"), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.",
"id": "GHSA-ph5r-c8gc-xg6f",
"modified": "2026-05-12T12:31:35Z",
"published": "2024-03-21T12:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26643"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-PHJ6-5VRC-G27M
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 18:31In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix deadlock in __mptcp_push_pending()
__mptcp_push_pending() may call mptcp_flush_join_list() with subflow socket lock held. If such call hits mptcp_sockopt_sync_all() then subsequently __mptcp_sockopt_sync() could try to lock the subflow socket for itself, causing a deadlock.
sysrq: Show Blocked State task:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000 Call Trace: __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160 ? do_wait_intr_irq+0xa0/0xa0 ? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9ba546c2d0 RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0 RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234 RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060 R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8
Fix the issue by using __mptcp_flush_join_list() instead of plain mptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by Florian. The sockopt sync will be deferred to the workqueue.
{
"affected": [],
"aliases": [
"CVE-2021-47590"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix deadlock in __mptcp_push_pending()\n\n__mptcp_push_pending() may call mptcp_flush_join_list() with subflow\nsocket lock held. If such call hits mptcp_sockopt_sync_all() then\nsubsequently __mptcp_sockopt_sync() could try to lock the subflow\nsocket for itself, causing a deadlock.\n\nsysrq: Show Blocked State\ntask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x2d6/0x10c0\n ? __mod_memcg_state+0x4d/0x70\n ? csum_partial+0xd/0x20\n ? _raw_spin_lock_irqsave+0x26/0x50\n schedule+0x4e/0xc0\n __lock_sock+0x69/0x90\n ? do_wait_intr_irq+0xa0/0xa0\n __lock_sock_fast+0x35/0x50\n mptcp_sockopt_sync_all+0x38/0xc0\n __mptcp_push_pending+0x105/0x200\n mptcp_sendmsg+0x466/0x490\n sock_sendmsg+0x57/0x60\n __sys_sendto+0xf0/0x160\n ? do_wait_intr_irq+0xa0/0xa0\n ? fpregs_restore_userregs+0x12/0xd0\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9ba546c2d0\nRSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0\nRDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234\nRBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060\nR13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8\n \u003c/TASK\u003e\n\nFix the issue by using __mptcp_flush_join_list() instead of plain\nmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by\nFlorian. The sockopt sync will be deferred to the workqueue.",
"id": "GHSA-phj6-5vrc-g27m",
"modified": "2024-08-27T18:31:35Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47590"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23311b92755ffa9087332d1bb8c71c0f6a10cc08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d79e3756ca90f7a6087b77b62c1d9c0801e0820"
}
],
"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-PJ73-39G5-XMF7
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-05 18:14In the Linux kernel, the following vulnerability has been resolved:
net: vlan: don't propagate flags on open
With the device instance lock, there is now a possibility of a deadlock:
[ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] _syssendmsg+0x1c8/0x220 [ 1.214164] _sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56
Device setup:
netdevsim0 (down)
^ ^
bond netdevsim1.100@netdevsim1 allmulticast=on (down)
When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev.
Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues.
Reproducer:
echo 0 1 > /sys/bus/netdevsim/new_device
dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)
ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up
ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-23163"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: don\u0027t propagate flags on open\n\nWith the device instance lock, there is now a possibility of a deadlock:\n\n[ 1.211455] ============================================\n[ 1.211571] WARNING: possible recursive locking detected\n[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted\n[ 1.211823] --------------------------------------------\n[ 1.211936] ip/184 is trying to acquire lock:\n[ 1.212032] ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0\n[ 1.212207]\n[ 1.212207] but task is already holding lock:\n[ 1.212332] ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_open+0x50/0xb0\n[ 1.212487]\n[ 1.212487] other info that might help us debug this:\n[ 1.212626] Possible unsafe locking scenario:\n[ 1.212626]\n[ 1.212751] CPU0\n[ 1.212815] ----\n[ 1.212871] lock(\u0026dev-\u003elock);\n[ 1.212944] lock(\u0026dev-\u003elock);\n[ 1.213016]\n[ 1.213016] *** DEADLOCK ***\n[ 1.213016]\n[ 1.213143] May be due to missing lock nesting notation\n[ 1.213143]\n[ 1.213294] 3 locks held by ip/184:\n[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0\n[ 1.213543] #1: ffffffff84e5fc70 (\u0026net-\u003ertnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0\n[ 1.213727] #2: ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_open+0x50/0xb0\n[ 1.213895]\n[ 1.213895] stack backtrace:\n[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5\n[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n[ 1.213994] Call Trace:\n[ 1.213995] \u003cTASK\u003e\n[ 1.213996] dump_stack_lvl+0x8e/0xd0\n[ 1.214000] print_deadlock_bug+0x28b/0x2a0\n[ 1.214020] lock_acquire+0xea/0x2a0\n[ 1.214027] __mutex_lock+0xbf/0xd40\n[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev-\u003eflags \u0026 IFF_ALLMULTI\n[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev\n[ 1.214042] __dev_open+0x145/0x270\n[ 1.214046] __dev_change_flags+0xb0/0x1e0\n[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev\n[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev-\u003evlan_info\n[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0\n[ 1.214058] notifier_call_chain+0x78/0x120\n[ 1.214062] netif_open+0x6d/0x90\n[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0\n[ 1.214066] bond_enslave+0x64c/0x1230\n[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0\n[ 1.214077] do_setlink+0x516/0x13b0\n[ 1.214094] rtnl_newlink+0xaba/0xb80\n[ 1.214132] rtnetlink_rcv_msg+0x440/0x490\n[ 1.214144] netlink_rcv_skb+0xeb/0x120\n[ 1.214150] netlink_unicast+0x1f9/0x320\n[ 1.214153] netlink_sendmsg+0x346/0x3f0\n[ 1.214157] __sock_sendmsg+0x86/0xb0\n[ 1.214160] ____sys_sendmsg+0x1c8/0x220\n[ 1.214164] ___sys_sendmsg+0x28f/0x2d0\n[ 1.214179] __x64_sys_sendmsg+0xef/0x140\n[ 1.214184] do_syscall_64+0xec/0x1d0\n[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 1.214191] RIP: 0033:0x7f2d1b4a7e56\n\nDevice setup:\n\n netdevsim0 (down)\n ^ ^\n bond netdevsim1.100@netdevsim1 allmulticast=on (down)\n\nWhen we enslave the lower device (netdevsim0) which has a vlan, we\npropagate vlan\u0027s allmuti/promisc flags during ndo_open. This causes\n(re)locking on of the real_dev.\n\nPropagate allmulti/promisc on flags change, not on the open. There\nis a slight semantics change that vlans that are down now propagate\nthe flags, but this seems unlikely to result in the real issues.\n\nReproducer:\n\n echo 0 1 \u003e /sys/bus/netdevsim/new_device\n\n dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*)\n dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)\n\n ip link set dev $dev name netdevsim0\n ip link set dev netdevsim0 up\n\n ip link add link netdevsim0 name netdevsim0.100 type vlan id 100\n ip link set dev netdevsim0.100 allm\n---truncated---",
"id": "GHSA-pj73-39g5-xmf7",
"modified": "2025-11-05T18:14:26Z",
"published": "2025-05-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27b918007d96402aba10ed52a6af8015230f1793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/299d7d27af6b5844cda06a0fdfa635705e1bc50f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/523fa0979d842443aa14b80002e45b471cbac137"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/538b43aa21e3b17c110104efd218b966d2eda5f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53fb25e90c0a503a17c639341ba5e755cb2feb5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8980018a9806743d9b80837330d46f06ecf78516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a32f1d4f1f4c9d978698f3c718621f6198f2e7ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1e3eeb037256a2f1206a8d69810ec47eb152026"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d537859e56bcc3091805c524484a4c85386b3cc8"
},
{
"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-PMJ2-RJQJ-CMF3
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519142.
{
"affected": [],
"aliases": [
"CVE-2023-20743"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:14Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519142.",
"id": "GHSA-pmj2-rjqj-cmf3",
"modified": "2024-04-04T04:35:38Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20743"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PMPX-W3F2-X2VP
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 18:31In the Linux kernel, the following vulnerability has been resolved:
ntfs3: fix circular locking dependency in run_unpack_ex
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.
The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().
This creates an AB-BA deadlock.
Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.
{
"affected": [],
"aliases": [
"CVE-2026-43127"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u003erw_lock\n(sbi-\u003eused.bitmap) and ni-\u003efile.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u003efile.run_lock then wnd-\u003erw_lock.\n2. run_unpack_ex() takes wnd-\u003erw_lock then tries to acquire\n ni-\u003efile.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u003erw_lock.",
"id": "GHSA-pmpx-w3f2-x2vp",
"modified": "2026-05-08T18:31:26Z",
"published": "2026-05-06T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08ce2fee1b869ecbfbd94e0eb2630e52203a2e03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b014372b62237521444ee51384549bdf48b79015"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8d22d9d8260b0f4f4d8e2898c98037c9982ea66"
}
],
"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.