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-JGPW-6HF2-C2M5
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
dpll: fix possible deadlock during netlink dump operation
Recently, I've been hitting following deadlock warning during dpll pin dump:
[52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529] ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock.
[52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}: [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578] __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742] __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984] __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845] __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022] __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this:
[52804.661077] Possible unsafe locking scenario:
[52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC); [52804.664490]
The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation.
Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order.
{
"affected": [],
"aliases": [
"CVE-2024-26725"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix possible deadlock during netlink dump operation\n\nRecently, I\u0027ve been hitting following deadlock warning during dpll pin\ndump:\n\n[52804.637962] ======================================================\n[52804.638536] WARNING: possible circular locking dependency detected\n[52804.639111] 6.8.0-rc2jiri+ #1 Not tainted\n[52804.639529] ------------------------------------------------------\n[52804.640104] python3/2984 is trying to acquire lock:\n[52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780\n[52804.641417]\n but task is already holding lock:\n[52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20\n[52804.642747]\n which lock already depends on the new lock.\n\n[52804.643551]\n the existing dependency chain (in reverse order) is:\n[52804.644259]\n -\u003e #1 (dpll_lock){+.+.}-{3:3}:\n[52804.644836] lock_acquire+0x174/0x3e0\n[52804.645271] __mutex_lock+0x119/0x1150\n[52804.645723] dpll_lock_dumpit+0x13/0x20\n[52804.646169] genl_start+0x266/0x320\n[52804.646578] __netlink_dump_start+0x321/0x450\n[52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0\n[52804.647575] genl_rcv_msg+0x1ed/0x3b0\n[52804.648001] netlink_rcv_skb+0xdc/0x210\n[52804.648440] genl_rcv+0x24/0x40\n[52804.648831] netlink_unicast+0x2f1/0x490\n[52804.649290] netlink_sendmsg+0x36d/0x660\n[52804.649742] __sock_sendmsg+0x73/0xc0\n[52804.650165] __sys_sendto+0x184/0x210\n[52804.650597] __x64_sys_sendto+0x72/0x80\n[52804.651045] do_syscall_64+0x6f/0x140\n[52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[52804.652001]\n -\u003e #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}:\n[52804.652650] check_prev_add+0x1ae/0x1280\n[52804.653107] __lock_acquire+0x1ed3/0x29a0\n[52804.653559] lock_acquire+0x174/0x3e0\n[52804.653984] __mutex_lock+0x119/0x1150\n[52804.654423] netlink_dump+0xb3/0x780\n[52804.654845] __netlink_dump_start+0x389/0x450\n[52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0\n[52804.655842] genl_rcv_msg+0x1ed/0x3b0\n[52804.656272] netlink_rcv_skb+0xdc/0x210\n[52804.656721] genl_rcv+0x24/0x40\n[52804.657119] netlink_unicast+0x2f1/0x490\n[52804.657570] netlink_sendmsg+0x36d/0x660\n[52804.658022] __sock_sendmsg+0x73/0xc0\n[52804.658450] __sys_sendto+0x184/0x210\n[52804.658877] __x64_sys_sendto+0x72/0x80\n[52804.659322] do_syscall_64+0x6f/0x140\n[52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[52804.660281]\n other info that might help us debug this:\n\n[52804.661077] Possible unsafe locking scenario:\n\n[52804.661671] CPU0 CPU1\n[52804.662129] ---- ----\n[52804.662577] lock(dpll_lock);\n[52804.662924] lock(nlk_cb_mutex-GENERIC);\n[52804.663538] lock(dpll_lock);\n[52804.664073] lock(nlk_cb_mutex-GENERIC);\n[52804.664490]\n\nThe issue as follows: __netlink_dump_start() calls control-\u003estart(cb)\nwith nlk-\u003ecb_mutex held. In control-\u003estart(cb) the dpll_lock is taken.\nThen nlk-\u003ecb_mutex is released and taken again in netlink_dump(), while\ndpll_lock still being held. That leads to ABBA deadlock when another\nCPU races with the same operation.\n\nFix this by moving dpll_lock taking into dumpit() callback which ensures\ncorrect lock taking order.",
"id": "GHSA-jgpw-6hf2-c2m5",
"modified": "2025-01-07T18:30:40Z",
"published": "2024-04-03T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26725"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/087739cbd0d0b87b6cec2c0799436ac66e24acc8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53c0441dd2c44ee93fddb5473885fd41e4bc2361"
}
],
"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-JGXP-FPW7-P364
Vulnerability from github – Published: 2025-05-29 15:31 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix region locking in hash types
Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.
{
"affected": [],
"aliases": [
"CVE-2025-37997"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-29T14:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.",
"id": "GHSA-jgxp-fpw7-p364",
"modified": "2025-12-16T21:30:50Z",
"published": "2025-05-29T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37997"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JHXV-JQ7P-9QHC
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 15:30In the Linux kernel, the following vulnerability has been resolved:
VMCI: Use threaded irqs instead of tasklets
The vmci_dispatch_dgs() tasklet function calls vmci_read_data() which uses wait_event() resulting in invalid sleep in an atomic context (and therefore potentially in a deadlock).
Use threaded irqs to fix this issue and completely remove usage of tasklets.
[ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145 [ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd [ 20.264645] preempt_count: 101, expected: 0 [ 20.264646] RCU nest depth: 0, expected: 0 [ 20.264647] 1 lock held by vmtoolsd/762: [ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock] [ 20.264658] Preemption disabled at: [ 20.264659] [] vmci_send_datagram+0x44/0xa0 [vmw_vmci] [ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1 [ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020 [ 20.264668] Call trace: [ 20.264669] dump_backtrace+0xc4/0x130 [ 20.264672] show_stack+0x24/0x80 [ 20.264673] dump_stack_lvl+0x88/0xb4 [ 20.264676] dump_stack+0x18/0x34 [ 20.264677] __might_resched+0x1a0/0x280 [ 20.264679] __might_sleep+0x58/0x90 [ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci] [ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci] [ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150 [ 20.264688] tasklet_action+0x40/0x50 [ 20.264689] __do_softirq+0x23c/0x6b4 [ 20.264690] __irq_exit_rcu+0x104/0x214 [ 20.264691] irq_exit_rcu+0x1c/0x50 [ 20.264693] el1_interrupt+0x38/0x6c [ 20.264695] el1h_64_irq_handler+0x18/0x24 [ 20.264696] el1h_64_irq+0x68/0x6c [ 20.264697] preempt_count_sub+0xa4/0xe0 [ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0 [ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci] [ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci] [ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci] [ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport] [ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport] [ 20.264713] vsock_connect+0x278/0x330 [vsock] [ 20.264715] __sys_connect_file+0x8c/0xc0 [ 20.264718] __sys_connect+0x84/0xb4 [ 20.264720] __arm64_sys_connect+0x2c/0x3c [ 20.264721] invoke_syscall+0x78/0x100 [ 20.264723] el0_svc_common.constprop.0+0x68/0x124 [ 20.264724] do_el0_svc+0x38/0x4c [ 20.264725] el0_svc+0x60/0x180 [ 20.264726] el0t_64_sync_handler+0x11c/0x150 [ 20.264728] el0t_64_sync+0x190/0x194
{
"affected": [],
"aliases": [
"CVE-2022-49759"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: Use threaded irqs instead of tasklets\n\nThe vmci_dispatch_dgs() tasklet function calls vmci_read_data()\nwhich uses wait_event() resulting in invalid sleep in an atomic\ncontext (and therefore potentially in a deadlock).\n\nUse threaded irqs to fix this issue and completely remove usage\nof tasklets.\n\n[ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145\n[ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd\n[ 20.264645] preempt_count: 101, expected: 0\n[ 20.264646] RCU nest depth: 0, expected: 0\n[ 20.264647] 1 lock held by vmtoolsd/762:\n[ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock]\n[ 20.264658] Preemption disabled at:\n[ 20.264659] [\u003cffff80000151d7d8\u003e] vmci_send_datagram+0x44/0xa0 [vmw_vmci]\n[ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1\n[ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020\n[ 20.264668] Call trace:\n[ 20.264669] dump_backtrace+0xc4/0x130\n[ 20.264672] show_stack+0x24/0x80\n[ 20.264673] dump_stack_lvl+0x88/0xb4\n[ 20.264676] dump_stack+0x18/0x34\n[ 20.264677] __might_resched+0x1a0/0x280\n[ 20.264679] __might_sleep+0x58/0x90\n[ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci]\n[ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci]\n[ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150\n[ 20.264688] tasklet_action+0x40/0x50\n[ 20.264689] __do_softirq+0x23c/0x6b4\n[ 20.264690] __irq_exit_rcu+0x104/0x214\n[ 20.264691] irq_exit_rcu+0x1c/0x50\n[ 20.264693] el1_interrupt+0x38/0x6c\n[ 20.264695] el1h_64_irq_handler+0x18/0x24\n[ 20.264696] el1h_64_irq+0x68/0x6c\n[ 20.264697] preempt_count_sub+0xa4/0xe0\n[ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0\n[ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci]\n[ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci]\n[ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci]\n[ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport]\n[ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport]\n[ 20.264713] vsock_connect+0x278/0x330 [vsock]\n[ 20.264715] __sys_connect_file+0x8c/0xc0\n[ 20.264718] __sys_connect+0x84/0xb4\n[ 20.264720] __arm64_sys_connect+0x2c/0x3c\n[ 20.264721] invoke_syscall+0x78/0x100\n[ 20.264723] el0_svc_common.constprop.0+0x68/0x124\n[ 20.264724] do_el0_svc+0x38/0x4c\n[ 20.264725] el0_svc+0x60/0x180\n[ 20.264726] el0t_64_sync_handler+0x11c/0x150\n[ 20.264728] el0t_64_sync+0x190/0x194",
"id": "GHSA-jhxv-jq7p-9qhc",
"modified": "2025-04-15T15:30:47Z",
"published": "2025-03-27T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49759"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3daed6345d5880464f46adab871d208e1baa2f3a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/548ea9dd5e01b0ecf53d2563004c80abd636743d"
}
],
"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-JM39-49Q3-98MM
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock().
[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc
Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context.
Relax the hrtimer not to use the hard context.
{
"affected": [],
"aliases": [
"CVE-2025-38335"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T09:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: gpio-keys - fix a sleep while atomic with PREEMPT_RT\n\nWhen enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in\nhard irq context, but the input_event() takes a spin_lock, which isn\u0027t\nallowed there as it is converted to a rt_spin_lock().\n\n[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0\n...\n[ 4054.290195] __might_resched+0x13c/0x1f4\n[ 4054.290209] rt_spin_lock+0x54/0x11c\n[ 4054.290219] input_event+0x48/0x80\n[ 4054.290230] gpio_keys_irq_timer+0x4c/0x78\n[ 4054.290243] __hrtimer_run_queues+0x1a4/0x438\n[ 4054.290257] hrtimer_interrupt+0xe4/0x240\n[ 4054.290269] arch_timer_handler_phys+0x2c/0x44\n[ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c\n[ 4054.290297] handle_irq_desc+0x40/0x58\n[ 4054.290307] generic_handle_domain_irq+0x1c/0x28\n[ 4054.290316] gic_handle_irq+0x44/0xcc\n\nConsidering the gpio_keys_irq_isr() can run in any context, e.g. it can\nbe threaded, it seems there\u0027s no point in requesting the timer isr to\nrun in hard irq context.\n\nRelax the hrtimer not to use the hard context.",
"id": "GHSA-jm39-49q3-98mm",
"modified": "2025-12-16T18:31:29Z",
"published": "2025-07-10T09:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38335"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/664e5a6f541ff226621487d1280d2ec28e86be28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7b79db25846459de63ca8974268f0c41c734c4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8f01e51109f77229e426b57c5d19251b462c6aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec8f5da79b425deef5aebacdd4fe645620cd4f0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4a8f561d08e39f7833d4a278ebfb12a41eef15f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa53beab4740c4e5fe969f218a379f9558be33dc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-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"
}
]
}
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.