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-GM6W-HJ88-5F6C
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18In ccu, there is a possible memory corruption 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: ALPS05594996; Issue ID: ALPS05594996.
{
"affected": [],
"aliases": [
"CVE-2021-0625"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-25T14:15:00Z",
"severity": "HIGH"
},
"details": "In ccu, there is a possible memory corruption 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: ALPS05594996; Issue ID: ALPS05594996.",
"id": "GHSA-gm6w-hj88-5f6c",
"modified": "2022-05-24T19:18:46Z",
"published": "2022-05-24T19:18:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0625"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/October-2021"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GP83-H9GH-VRV6
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-11-01 15:31In the Linux kernel, the following vulnerability has been resolved:
net: systemport: Add global locking for descriptor lifecycle
The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues.
This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length.
The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer.
The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITE_PORT_{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used.
{
"affected": [],
"aliases": [
"CVE-2021-47587"
],
"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\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used.",
"id": "GHSA-gp83-h9gh-vrv6",
"modified": "2024-11-01T15:31:45Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47587"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/595a684fa6f23b21958379a18cfa83862c73c2e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e1011cd183faae8daff275c72444edcdfe0d473"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b8e6e782456f1ce02a7ae914bbd5b1053f0b034"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ed2f5d08d6e59f8c78b2869bfb95d0be32c094c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c675256a7f131f5ba3f331efb715e8f31ea0e392"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de57f62f76450b934de8203711bdc4f7953c3421"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb4687c7442942e115420a30185f8d83faf37696"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3fde37d3f0d429f0fcce214cb52588a9e21260e"
}
],
"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-GR3W-P7MM-8PCQ
Vulnerability from github – Published: 2024-08-08 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races.
The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs().
The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system.
- Normal case
0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3
- Race case
0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
{
"affected": [],
"aliases": [
"CVE-2024-42253"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-08T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: pca953x: fix pca953x_irq_bus_sync_unlock race\n\nEnsure that `i2c_lock\u0027 is held when setting interrupt latch and mask in\npca953x_irq_bus_sync_unlock() in order to avoid races.\n\nThe other (non-probe) call site pca953x_gpio_set_multiple() ensures the\nlock is held before calling pca953x_write_regs().\n\nThe problem occurred when a request raced against irq_bus_sync_unlock()\napproximately once per thousand reboots on an i.MX8MP based system.\n\n * Normal case\n\n 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0\n 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0\n 0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n 0-0022: write register AI|12 {fc,00,00,00,00} Config P3\n\n * Race case\n\n 0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***\n 0-0022: write register AI|12 {fc,00,00,00,00} Config P3\n 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0",
"id": "GHSA-gr3w-p7mm-8pcq",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-08T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42253"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GR8X-8Q27-R5GG
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.
{
"affected": [],
"aliases": [
"CVE-2024-56531"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor.",
"id": "GHSA-gr8x-8q27-r5gg",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56531"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
},
{
"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-GRQ2-2V86-6PPX
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13The Bluetooth Classic implementation on Zhuhai Jieli AC690X and AC692X devices does not properly handle an out-of-order LMP Setup procedure that is followed by a malformed LMP packet, allowing attackers in radio range to deadlock a device via a crafted LMP packet. The user needs to manually reboot the device to restore communication.
{
"affected": [],
"aliases": [
"CVE-2021-31611"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-07T07:15:00Z",
"severity": "MODERATE"
},
"details": "The Bluetooth Classic implementation on Zhuhai Jieli AC690X and AC692X devices does not properly handle an out-of-order LMP Setup procedure that is followed by a malformed LMP packet, allowing attackers in radio range to deadlock a device via a crafted LMP packet. The user needs to manually reboot the device to restore communication.",
"id": "GHSA-grq2-2v86-6ppx",
"modified": "2022-05-24T19:13:16Z",
"published": "2022-05-24T19:13:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31611"
},
{
"type": "WEB",
"url": "https://dl.packetstormsecurity.net/papers/general/braktooth.pdf"
},
{
"type": "WEB",
"url": "https://launchstudio.bluetooth.com/ListingDetails/19746"
},
{
"type": "WEB",
"url": "https://launchstudio.bluetooth.com/ListingDetails/58628"
},
{
"type": "WEB",
"url": "http://www.zh-jieli.com/product/68-cn.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GRRP-5MC5-CCMG
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Don't hold the layoutget locks across multiple RPC calls
When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49316"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Don\u0027t hold the layoutget locks across multiple RPC calls\n\nWhen doing layoutget as part of the open() compound, we have to be\ncareful to release the layout locks before we can call any further RPC\ncalls, such as setattr(). The reason is that those calls could trigger\na recall, which could deadlock.",
"id": "GHSA-grrp-5mc5-ccmg",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49316"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1"
}
],
"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-GV5W-824R-R7XX
Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2025-09-19 21:31In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()
qdisc_tree_reduce_backlog() is called with the qdisc lock held, not RTNL.
We must use qdisc_lookup_rcu() instead of qdisc_lookup()
syzbot reported:
WARNING: suspicious RCU usage 6.1.74-syzkaller #0 Not tainted
net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 3 locks held by udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792
stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: [] __dump_stack lib/dump_stack.c:88 [inline] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [] qdisc_enqueue include/net/sch_generic.h:833 [inline] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [inline] [] qdisc_restart net/sched/sch_generic.c:397 [inline] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c:447 [inline] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656
{
"affected": [],
"aliases": [
"CVE-2024-35892"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T09:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix lockdep splat in qdisc_tree_reduce_backlog()\n\nqdisc_tree_reduce_backlog() is called with the qdisc lock held,\nnot RTNL.\n\nWe must use qdisc_lookup_rcu() instead of qdisc_lookup()\n\nsyzbot reported:\n\nWARNING: suspicious RCU usage\n6.1.74-syzkaller #0 Not tainted\n-----------------------------\nnet/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n3 locks held by udevd/1142:\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282\n #1: ffff888171861108 (\u0026sch-\u003eq.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]\n #1: ffff888171861108 (\u0026sch-\u003eq.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792\n\nstack backtrace:\nCPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u003cTASK\u003e\n [\u003cffffffff85b85f14\u003e] __dump_stack lib/dump_stack.c:88 [inline]\n [\u003cffffffff85b85f14\u003e] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106\n [\u003cffffffff85b86007\u003e] dump_stack+0x15/0x1e lib/dump_stack.c:113\n [\u003cffffffff81802299\u003e] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592\n [\u003cffffffff84f0054c\u003e] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305\n [\u003cffffffff84f037c3\u003e] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811\n [\u003cffffffff84f5b78c\u003e] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51\n [\u003cffffffff84fbcf63\u003e] qdisc_enqueue include/net/sch_generic.h:833 [inline]\n [\u003cffffffff84fbcf63\u003e] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723\n [\u003cffffffff84eecab9\u003e] dequeue_skb net/sched/sch_generic.c:292 [inline]\n [\u003cffffffff84eecab9\u003e] qdisc_restart net/sched/sch_generic.c:397 [inline]\n [\u003cffffffff84eecab9\u003e] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415\n [\u003cffffffff84d7aa96\u003e] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125\n [\u003cffffffff84d85d29\u003e] net_tx_action+0x7c9/0x970 net/core/dev.c:5313\n [\u003cffffffff85e002bd\u003e] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616\n [\u003cffffffff81568bca\u003e] invoke_softirq kernel/softirq.c:447 [inline]\n [\u003cffffffff81568bca\u003e] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700\n [\u003cffffffff81568ae9\u003e] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712\n [\u003cffffffff85b89f52\u003e] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107\n [\u003cffffffff85c00ccb\u003e] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656",
"id": "GHSA-gv5w-824r-r7xx",
"modified": "2025-09-19T21:31:15Z",
"published": "2024-05-19T09:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35892"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e"
}
],
"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-GV6C-55WW-R8WV
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-25 18:30In the Linux kernel, the following vulnerability has been resolved:
ext4: fix racy may inline data check in dio write
syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below:
if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
return -ERANGE;
This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data.
The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds.
The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race.
{
"affected": [],
"aliases": [
"CVE-2023-52786"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix racy may inline data check in dio write\n\nsyzbot reports that the following warning from ext4_iomap_begin()\ntriggers as of the commit referenced below:\n\n if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\n return -ERANGE;\n\nThis occurs during a dio write, which is never expected to encounter\nan inode with inline data. To enforce this behavior,\next4_dio_write_iter() checks the current inline state of the inode\nand clears the MAY_INLINE_DATA state flag to either fall back to\nbuffered writes, or enforce that any other writers in progress on\nthe inode are not allowed to create inline data.\n\nThe problem is that the check for existing inline data and the state\nflag can span a lock cycle. For example, if the ilock is originally\nlocked shared and subsequently upgraded to exclusive, another writer\nmay have reacquired the lock and created inline data before the dio\nwrite task acquires the lock and proceeds.\n\nThe commit referenced below loosens the lock requirements to allow\nsome forms of unaligned dio writes to occur under shared lock, but\nAFAICT the inline data check was technically already racy for any\ndio write that would have involved a lock cycle. Regardless, lift\nclearing of the state bit to the same lock critical section that\nchecks for preexisting inline data on the inode to close the race.",
"id": "GHSA-gv6c-55ww-r8wv",
"modified": "2025-09-25T18:30:28Z",
"published": "2024-05-21T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52786"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GVMP-GR98-MP6J
Vulnerability from github – Published: 2022-04-29 02:57 – Updated: 2024-02-15 21:31Apache 1.4.x before 1.3.30, and 2.0.x before 2.0.49, when using multiple listening sockets on certain platforms, allows remote attackers to cause a denial of service (blocked new connections) via a "short-lived connection on a rarely-accessed listening socket."
{
"affected": [],
"aliases": [
"CVE-2004-0174"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2004-05-04T04:00:00Z",
"severity": "MODERATE"
},
"details": "Apache 1.4.x before 1.3.30, and 2.0.x before 2.0.49, when using multiple listening sockets on certain platforms, allows remote attackers to cause a denial of service (blocked new connections) via a \"short-lived connection on a rarely-accessed listening socket.\"",
"id": "GHSA-gvmp-gr98-mp6j",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-04-29T02:57:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2004-0174"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raa117ef183f0da9b3f46efbeaa66f7622bd68868a450cae4fd8ed594%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raa117ef183f0da9b3f46efbeaa66f7622bd68868a450cae4fd8ed594@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd65d8ba68ba17e7deedafbf5bb4899f2ae4dad781d21b931c2941ac3%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd65d8ba68ba17e7deedafbf5bb4899f2ae4dad781d21b931c2941ac3@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re895fc1736d25c8cf57e102c871613b8aeec9ea26fd8a44e7942b5ab%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re895fc1736d25c8cf57e102c871613b8aeec9ea26fd8a44e7942b5ab@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf2f0f3611f937cf6cfb3b4fe4a67f69885855126110e1e3f2fb2728e%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf2f0f3611f937cf6cfb3b4fe4a67f69885855126110e1e3f2fb2728e@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A100110"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1982"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15540"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5419c9ba0951ef73a655362403d12bb8d10fab38274deb3f005816f5%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5419c9ba0951ef73a655362403d12bb8d10fab38274deb3f005816f5@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=107973894328806\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=108066914830552\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=108369640424244\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=108437852004207\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=108731648532365\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/11170"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200405-22.xml"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-101555-1"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-57628-1"
},
{
"type": "WEB",
"url": "http://www.apache.org/dist/httpd/CHANGES_1.3"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/132110"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2004:046"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2004-405.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/9921"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/alerts/2004/Mar/1009495.html"
},
{
"type": "WEB",
"url": "http://www.slackware.com/security/viewer.php?l=slackware-security\u0026y=2004\u0026m=slackware-security.529643"
},
{
"type": "WEB",
"url": "http://www.trustix.org/errata/2004/0027"
}
],
"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-GVXC-64WH-VGV2
Vulnerability from github – Published: 2024-04-10 21:30 – Updated: 2024-11-01 18:31In the Linux kernel, the following vulnerability has been resolved:
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:
Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.
{
"affected": [],
"aliases": [
"CVE-2021-47185"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T19:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\n\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\n\n Workqueue: events_unbound flush_to_ldisc\n Call trace:\n dump_backtrace+0x0/0x1ec\n show_stack+0x24/0x30\n dump_stack+0xd0/0x128\n panic+0x15c/0x374\n watchdog_timer_fn+0x2b8/0x304\n __run_hrtimer+0x88/0x2c0\n __hrtimer_run_queues+0xa4/0x120\n hrtimer_interrupt+0xfc/0x270\n arch_timer_handler_phys+0x40/0x50\n handle_percpu_devid_irq+0x94/0x220\n __handle_domain_irq+0x88/0xf0\n gic_handle_irq+0x84/0xfc\n el1_irq+0xc8/0x180\n slip_unesc+0x80/0x214 [slip]\n tty_ldisc_receive_buf+0x64/0x80\n tty_port_default_receive_buf+0x50/0x90\n flush_to_ldisc+0xbc/0x110\n process_one_work+0x1d4/0x4b0\n worker_thread+0x180/0x430\n kthread+0x11c/0x120\n\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it.",
"id": "GHSA-gvxc-64wh-vgv2",
"modified": "2024-11-01T18:31:25Z",
"published": "2024-04-10T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47185"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/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.