CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
713 vulnerabilities reference this CWE, most recent first.
GHSA-JPH2-WV5J-5W33
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
Performance counter stats for 'sleep 5':
0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
5.002117947 seconds time elapsed
0.000131000 seconds user
0.001063000 seconds sys
Below is snippet of the warning in dmesg:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1
The above warning triggered because the current imc-pmu code uses mutex lock in interrupt disabled sections. The function mutex_lock() internally calls __might_resched(), which will check if IRQs are disabled and in case IRQs are disabled, it will trigger the warning.
Fix the issue by changing the mutex lock to spinlock.
[mpe: Fix comments, trim oops in change log, add reported-by tags]
{
"affected": [],
"aliases": [
"CVE-2023-53031"
],
"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\npowerpc/imc-pmu: Fix use of mutex in IRQs disabled section\n\nCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP\nand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.\n\nCommand to trigger the warning:\n # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5\n\n Performance counter stats for \u0027sleep 5\u0027:\n\n 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/\n\n 5.002117947 seconds time elapsed\n\n 0.000131000 seconds user\n 0.001063000 seconds sys\n\nBelow is snippet of the warning in dmesg:\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec\n preempt_count: 2, expected: 0\n 4 locks held by perf-exec/2869:\n #0: c00000004325c540 (\u0026sig-\u003ecred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90\n #1: c00000004325c5d8 (\u0026sig-\u003eexec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0\n #2: c0000003fa99d4e0 (\u0026cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510\n #3: c000000017ab8418 (\u0026ctx-\u003elock){....}-{2:2}, at: perf_event_exec+0x29c/0x510\n irq event stamp: 4806\n hardirqs last enabled at (4805): [\u003cc000000000f65b94\u003e] _raw_spin_unlock_irqrestore+0x94/0xd0\n hardirqs last disabled at (4806): [\u003cc0000000003fae44\u003e] perf_event_exec+0x394/0x510\n softirqs last enabled at (0): [\u003cc00000000013c404\u003e] copy_process+0xc34/0x1ff0\n softirqs last disabled at (0): [\u003c0000000000000000\u003e] 0x0\n CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61\n Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n Call Trace:\n dump_stack_lvl+0x98/0xe0 (unreliable)\n __might_resched+0x2f8/0x310\n __mutex_lock+0x6c/0x13f0\n thread_imc_event_add+0xf4/0x1b0\n event_sched_in+0xe0/0x210\n merge_sched_in+0x1f0/0x600\n visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0\n ctx_flexible_sched_in+0xcc/0x140\n ctx_sched_in+0x20c/0x2a0\n ctx_resched+0x104/0x1c0\n perf_event_exec+0x340/0x510\n begin_new_exec+0x730/0xef0\n load_elf_binary+0x3f8/0x1e10\n ...\n do not call blocking ops when !TASK_RUNNING; state=2001 set at [\u003c00000000fd63e7cf\u003e] do_nanosleep+0x60/0x1a0\n WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0\n CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61\n Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670\n REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2)\n MSR: 9000000000021033 \u003cSF,HV,ME,IR,DR,RI,LE\u003e CR: 48002824 XER: 00000000\n CFAR: c00000000013fb64 IRQMASK: 1\n\nThe above warning triggered because the current imc-pmu code uses mutex\nlock in interrupt disabled sections. The function mutex_lock()\ninternally calls __might_resched(), which will check if IRQs are\ndisabled and in case IRQs are disabled, it will trigger the warning.\n\nFix the issue by changing the mutex lock to spinlock.\n\n[mpe: Fix comments, trim oops in change log, add reported-by tags]",
"id": "GHSA-jph2-wv5j-5w33",
"modified": "2025-10-31T21:30:52Z",
"published": "2025-03-27T18:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53031"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/424bcb570cb320d1d15238cd4c933522b90f78fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76d588dddc459fefa1da96e0a081a397c5c8e216"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cbeb60320ac45a8240b561c8ef466b86c34dedc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a90d339f1f66be4a946769b565668e2bd0686dfa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0c6d2a31026102d4738b47a610bed4401b9834f"
}
],
"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-JPJ8-HW92-VQGG
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix deadlocks between devlink and netdev instance locks
In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering.
The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock.
But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover
The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout
Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.
{
"affected": [],
"aliases": [
"CVE-2026-45907"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlocks between devlink and netdev instance locks\n\nIn the mentioned \"Fixes\" commit, various work tasks triggering devlink\nhealth reporter recovery were switched to use netdev_trylock to protect\nagainst concurrent tear down of the channels being recovered. But this\nhad the side effect of introducing potential deadlocks because of\nincorrect lock ordering.\n\nThe correct lock order is described by the init flow:\nprobe_one -\u003e mlx5_init_one (acquires devlink lock)\n-\u003e mlx5_init_one_devl_locked -\u003e mlx5_register_device\n-\u003e mlx5_rescan_drivers_locked -...-\u003e mlx5e_probe -\u003e _mlx5e_probe\n-\u003e register_netdev (acquires rtnl lock)\n-\u003e register_netdevice (acquires netdev lock)\n=\u003e devlink lock -\u003e rtnl lock -\u003e netdev lock.\n\nBut in the current recovery flow, the order is wrong:\nmlx5e_tx_err_cqe_work (acquires netdev lock)\n-\u003e mlx5e_reporter_tx_err_cqe -\u003e mlx5e_health_report\n-\u003e devlink_health_report (acquires devlink lock =\u003e boom!)\n-\u003e devlink_health_reporter_recover\n-\u003e mlx5e_tx_reporter_recover -\u003e mlx5e_tx_reporter_recover_from_ctx\n-\u003e mlx5e_tx_reporter_err_cqe_recover\n\nThe same pattern exists in:\nmlx5e_reporter_rx_timeout\nmlx5e_reporter_tx_ptpsq_unhealthy\nmlx5e_reporter_tx_timeout\n\nFix these by moving the netdev_trylock calls from the work handlers\nlower in the call stack, in the respective recovery functions, where\nthey are actually necessary.",
"id": "GHSA-jpj8-hw92-vqgg",
"modified": "2026-06-24T18:32:27Z",
"published": "2026-05-27T15:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45907"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9"
}
],
"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-JQX2-5F2V-644H
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: move wait_on_sem() out of spinlock
With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled.
Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled.
{
"affected": [],
"aliases": [
"CVE-2026-43253"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: move wait_on_sem() out of spinlock\n\nWith iommu.strict=1, the existing completion wait path can cause soft\nlockups under stressed environment, as wait_on_sem() busy-waits under the\nspinlock with interrupts disabled.\n\nMove the completion wait in iommu_completion_wait() out of the spinlock.\nwait_on_sem() only polls the hardware-updated cmd_sem and does not require\niommu-\u003elock, so holding the lock during the busy wait unnecessarily\nincreases contention and extends the time with interrupts disabled.",
"id": "GHSA-jqx2-5f2v-644h",
"modified": "2026-05-08T15:31:18Z",
"published": "2026-05-06T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43253"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/496269d12072ecb219826485bdbec70c92a8eef5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/715c263119fd1b918a9fcbd8a36ea5b604a46324"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2a0cac10597068567d336e85fa3cbdbe8ca62bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e15768e68820142077bbca402d8e902f64ade1b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2f65b28d802a667119147444ec2ae33eebf9a58"
}
],
"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-JW27-39XW-8FJX
Vulnerability from github – Published: 2025-12-12 21:31 – Updated: 2026-03-20 18:31A memory corruption issue was addressed with improved lock state checking. This issue is fixed in watchOS 26.1, iOS 18.7.2 and iPadOS 18.7.2, macOS Tahoe 26.1, visionOS 26.1, tvOS 26.1, macOS Sonoma 14.8.2, macOS Sequoia 15.7.2, iOS 26.1 and iPadOS 26.1. A malicious application may cause unexpected changes in memory shared between processes.
{
"affected": [],
"aliases": [
"CVE-2025-43510"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-12T21:15:55Z",
"severity": "HIGH"
},
"details": "A memory corruption issue was addressed with improved lock state checking. This issue is fixed in watchOS 26.1, iOS 18.7.2 and iPadOS 18.7.2, macOS Tahoe 26.1, visionOS 26.1, tvOS 26.1, macOS Sonoma 14.8.2, macOS Sequoia 15.7.2, iOS 26.1 and iPadOS 26.1. A malicious application may cause unexpected changes in memory shared between processes.",
"id": "GHSA-jw27-39xw-8fjx",
"modified": "2026-03-20T18:31:15Z",
"published": "2025-12-12T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43510"
},
{
"type": "WEB",
"url": "https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125632"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125633"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125634"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125635"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125636"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125637"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125638"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125639"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-43510"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JW2V-CQ5X-Q68G
Vulnerability from github – Published: 2026-01-20 16:30 – Updated: 2026-02-02 22:21Summary
Pterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle.
However, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time.
As a result a server would be able to create more databases, allocations, or backups than configured.
Impact
A malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pterodactyl/panel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69198"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-400",
"CWE-413",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-20T16:30:17Z",
"nvd_published_at": "2026-01-19T19:16:03Z",
"severity": "MODERATE"
},
"details": "### Summary\nPterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle.\n\nHowever, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time.\n\nAs a result a server would be able to create more databases, allocations, or backups than configured.\n\n### Impact\nA malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system.",
"id": "GHSA-jw2v-cq5x-q68g",
"modified": "2026-02-02T22:21:44Z",
"published": "2026-01-20T16:30:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-jw2v-cq5x-q68g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69198"
},
{
"type": "WEB",
"url": "https://github.com/pterodactyl/panel/commit/09caa0d4995bd924b53b9a9e9b4883ac27bd5607"
},
{
"type": "PACKAGE",
"url": "https://github.com/pterodactyl/panel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Pterodactyl improperly locks resources allowing raced queries to create more resources than alloted"
}
GHSA-M24R-P59V-Q652
Vulnerability from github – Published: 2023-07-18 18:30 – Updated: 2024-04-04 06:13A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2023-0160"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-18T17:15:11Z",
"severity": "MODERATE"
},
"details": "A deadlock flaw was found in the Linux kernel\u2019s BPF subsystem. This flaw allows a local user to potentially crash the system.",
"id": "GHSA-m24r-p59v-q652",
"modified": "2024-04-04T06:13:54Z",
"published": "2023-07-18T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0160"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-0160"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2159764"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com"
}
],
"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-M2V9-W374-5HJ9
Vulnerability from github – Published: 2024-04-25 19:50 – Updated: 2025-01-14 16:37Summary
Prior to v0.3.0, __default__() functions did not respect the @nonreentrancy decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.
A contract search was additionally performed and no vulnerable contracts were found in production.
PoC
@external
@payable
@nonreentrant("default")
def __default__():
pass
after codegen:
[seq,
[if, [lt, calldatasize, 4], [goto, fallback]],
[mstore, 28, [calldataload, 0]],
[with, _func_sig, [mload, 0], seq],
[seq_unchecked,
[label, fallback],
[seq,
pass,
# Line 5
pass,
pass,
# Line 4
stop]]],
Impact
No vulnerable production contracts were found. Additionally, using a lock on a default function is a very sparsely used pattern. As such, the impact is low.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.16"
},
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32648"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T19:50:35Z",
"nvd_published_at": "2024-04-25T18:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\nPrior to v0.3.0, `__default__()` functions did not respect the `@nonreentrancy` decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.\n\nA contract search was additionally performed and no vulnerable contracts were found in production.\n\n### PoC\n```vyper\n@external\n@payable\n@nonreentrant(\"default\")\ndef __default__():\n pass\n```\n\nafter codegen:\n```\n[seq,\n [if, [lt, calldatasize, 4], [goto, fallback]],\n [mstore, 28, [calldataload, 0]],\n [with, _func_sig, [mload, 0], seq],\n [seq_unchecked,\n [label, fallback],\n [seq,\n pass,\n # Line 5\n pass,\n pass,\n # Line 4\n stop]]],\n```\n\n### Impact\nNo vulnerable production contracts were found. Additionally, using a lock on a `default` function is a very sparsely used pattern. As such, the impact is `low`.\n",
"id": "GHSA-m2v9-w374-5hj9",
"modified": "2025-01-14T16:37:11Z",
"published": "2024-04-25T19:50:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-m2v9-w374-5hj9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32648"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/issues/2455"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/93287e5ac184b53b395c907d40701f721daf8177"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-163.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vyperlang/vyper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "vyper default functions don\u0027t respect nonreentrancy keys"
}
GHSA-M484-77R4-H4VF
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-08-21 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: Fix a deadlock in the error handler
The following deadlock has been observed on a test setup:
-
All tags allocated
-
The SCSI error handler calls ufshcd_eh_host_reset_handler()
-
ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
-
ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request.
{
"affected": [],
"aliases": [
"CVE-2021-47622"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: Fix a deadlock in the error handler\n\nThe following deadlock has been observed on a test setup:\n\n - All tags allocated\n\n - The SCSI error handler calls ufshcd_eh_host_reset_handler()\n\n - ufshcd_eh_host_reset_handler() queues work that calls\n ufshcd_err_handler()\n\n - ufshcd_err_handler() locks up as follows:\n\nWorkqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt\nCall trace:\n __switch_to+0x298/0x5d8\n __schedule+0x6cc/0xa94\n schedule+0x12c/0x298\n blk_mq_get_tag+0x210/0x480\n __blk_mq_alloc_request+0x1c8/0x284\n blk_get_request+0x74/0x134\n ufshcd_exec_dev_cmd+0x68/0x640\n ufshcd_verify_dev_init+0x68/0x35c\n ufshcd_probe_hba+0x12c/0x1cb8\n ufshcd_host_reset_and_restore+0x88/0x254\n ufshcd_reset_and_restore+0xd0/0x354\n ufshcd_err_handler+0x408/0xc58\n process_one_work+0x24c/0x66c\n worker_thread+0x3e8/0xa4c\n kthread+0x150/0x1b4\n ret_from_fork+0x10/0x30\n\nFix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved\nrequest.",
"id": "GHSA-m484-77r4-h4vf",
"modified": "2024-08-21T18:31:26Z",
"published": "2024-07-16T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47622"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768"
}
],
"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-M4W5-F9XF-8FGR
Vulnerability from github – Published: 2025-02-09 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
gpio: xilinx: Convert gpio_lock to raw spinlock
irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking.
This fixes the following lockdep splat:
[ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)
{
"affected": [],
"aliases": [
"CVE-2025-21684"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-09T12:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: xilinx: Convert gpio_lock to raw spinlock\n\nirq_chip functions may be called in raw spinlock context. Therefore, we\nmust also use a raw spinlock for our own internal locking.\n\nThis fixes the following lockdep splat:\n\n[ 5.349336] =============================\n[ 5.353349] [ BUG: Invalid wait context ]\n[ 5.357361] 6.13.0-rc5+ #69 Tainted: G W\n[ 5.363031] -----------------------------\n[ 5.367045] kworker/u17:1/44 is trying to lock:\n[ 5.371587] ffffff88018b02c0 (\u0026chip-\u003egpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.380079] other info that might help us debug this:\n[ 5.385138] context-{5:5}\n[ 5.387762] 5 locks held by kworker/u17:1/44:\n[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)\n[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)\n[ 5.411528] #2: ffffff880172c900 (\u0026dev-\u003emutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)\n[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)\n[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)\n[ 5.436472] stack backtrace:\n[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69\n[ 5.448690] Tainted: [W]=WARN\n[ 5.451656] Hardware name: xlnx,zynqmp (DT)\n[ 5.455845] Workqueue: events_unbound deferred_probe_work_func\n[ 5.461699] Call trace:\n[ 5.464147] show_stack+0x18/0x24 C\n[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)\n[ 5.471501] dump_stack (lib/dump_stack.c:130)\n[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)\n[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)\n[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)\n[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)\n[ 5.497645] irq_startup (kernel/irq/chip.c:270)\n[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)\n[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)",
"id": "GHSA-m4w5-f9xf-8fgr",
"modified": "2025-11-03T21:32:35Z",
"published": "2025-02-09T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21684"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d25041d4a3b2af64c888cf762362b2528ba59294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b"
},
{
"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-M5Q9-GX2F-VVF3
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-09-06 18:31In the Linux kernel, the following vulnerability has been resolved:
xen: privcmd: Switch from mutex to spinlock for irqfds
irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock.
Fix it by switching over to a spin lock.
{
"affected": [],
"aliases": [
"CVE-2024-44957"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(\u0026ctx-\u003ewqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can\u0027t use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock.",
"id": "GHSA-m5q9-gx2f-vvf3",
"modified": "2024-09-06T18:31:28Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c"
}
],
"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.