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-37VF-XCVF-JRJR
Vulnerability from github – Published: 2026-01-14 15:32 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-71104"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T15:15:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0027s APIC timer in periodic\nmode, set the expiration to \"now\" if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0027s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0027s request for an expiration in the past and\nimmediately re-invokes KVM\u0027s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0027s hrtimer\nover and over until the target expiration is advanced to \"now\" can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u003cIRQ\u003e\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u003c/IRQ\u003e\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\"KVM: VMX: Move preemption timer \u003c=\u003e hrtimer dance to common x86\"), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---",
"id": "GHSA-37vf-xcvf-jrjr",
"modified": "2026-07-14T15:31:32Z",
"published": "2026-01-14T15:32:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18ab3fc8e880791aa9f7c000261320fc812b5465"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/786ed625c125c5cd180d6aaa37e653e3e4ffb8d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b54ccef865e0aa62e4871d4ada2ba4b9dcb8bed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/807dbe8f3862fa7c164155857550ce94b36a11b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2da0df7bbc4fb4fd7d0a1da704f81a09c72fe73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e23f46f1a971c73dad2fd63e1408696114ddebe2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e746e51947053a02af2ea964593dc4887108d379"
}
],
"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-38P5-W7J2-VWRV
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.
{
"affected": [],
"aliases": [
"CVE-2025-39782"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.",
"id": "GHSA-38p5-w7j2-vwrv",
"modified": "2026-07-14T15:31:27Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39782"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26cb9aad94cb1811d8fae115594cc71fa3d91ab0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3faac5e1d14c63260fd1bf789d96bde3ab3d9e54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41f40038de62e8306897cf6840791b268996432a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/429d50cbaff45090d52a1ea850d5de8c14881ee7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84ff98c1ea19acd3f9389e4bb6061364e943f85e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d98cf4632258720f18265a058e62fde120c0151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f683d611518d30334813eecf9a8c687453e2800e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7ee8fd689e6d534f9fd2494b9266f7998082e65"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"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-3C2R-W857-W87R
Vulnerability from github – Published: 2022-01-05 00:00 – Updated: 2022-01-12 00:01In vow driver, 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: ALPS05862986; Issue ID: ALPS05862986.
{
"affected": [],
"aliases": [
"CVE-2022-20016"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-04T16:15:00Z",
"severity": "MODERATE"
},
"details": "In vow driver, 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: ALPS05862986; Issue ID: ALPS05862986.",
"id": "GHSA-3c2r-w857-w87r",
"modified": "2022-01-12T00:01:35Z",
"published": "2022-01-05T00:00:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20016"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/January-2022"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3F4P-8QJ7-5FXP
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-10-28 03:30In the Linux kernel, the following vulnerability has been resolved:
block: mark GFP_NOIO around sysfs ->store()
sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused.
Fix the issue by marking NOIO around sysfs ->store()
{
"affected": [],
"aliases": [
"CVE-2025-21817"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: mark GFP_NOIO around sysfs -\u003estore()\n\nsysfs -\u003estore is called with queue freezed, meantime we have several\n-\u003estore() callbacks(update_nr_requests, wbt, scheduler) to allocate\nmemory with GFP_KERNEL which may run into direct reclaim code path,\nthen potential deadlock can be caused.\n\nFix the issue by marking NOIO around sysfs -\u003estore()",
"id": "GHSA-3f4p-8qj7-5fxp",
"modified": "2025-10-28T03:30:13Z",
"published": "2025-02-27T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21817"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2566ce907e5d5db8a039647208e029ce559baa31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c0be4ead1f8f5f8be0803f347de0de81e3b8e1c"
}
],
"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-3FPR-88W3-V99M
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0
============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
lock(team->team_lock_key); lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)
{
"affected": [],
"aliases": [
"CVE-2024-58071"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nteam: prevent adding a device which is already a team device lower\n\nPrevent adding a device which is already a team device lower,\ne.g. adding veth0 if vlan1 was already added and veth0 is a lower of\nvlan1.\n\nThis is not useful in practice and can lead to recursive locking:\n\n$ ip link add veth0 type veth peer name veth1\n$ ip link set veth0 up\n$ ip link set veth1 up\n$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1\n$ ip link add team0 type team\n$ ip link set veth0.1 down\n$ ip link set veth0.1 master team0\nteam0: Port device veth0.1 added\n$ ip link set veth0 down\n$ ip link set veth0 master team0\n\n============================================\nWARNING: possible recursive locking detected\n6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted\n--------------------------------------------\nip/7684 is trying to acquire lock:\nffff888016848e00 (team-\u003eteam_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n\nbut task is already holding lock:\nffff888016848e00 (team-\u003eteam_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\n\nCPU0\n----\nlock(team-\u003eteam_lock_key);\nlock(team-\u003eteam_lock_key);\n\n*** DEADLOCK ***\n\nMay be due to missing lock nesting notation\n\n2 locks held by ip/7684:\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl (lib/dump_stack.c:122)\nprint_deadlock_bug.cold (kernel/locking/lockdep.c:3040)\n__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)\n? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)\nlock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? lock_acquire (kernel/locking/lockdep.c:5822)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? fib_sync_up (net/ipv4/fib_semantics.c:2167)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nteam_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\n__dev_notify_flags (net/core/dev.c:8993)\n? __dev_change_flags (net/core/dev.c:8975)\ndev_change_flags (net/core/dev.c:9027)\nvlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)\n? br_device_event (net/bridge/br.c:143)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\ndev_open (net/core/dev.c:1519 net/core/dev.c:1505)\nteam_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)\n? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)\ndo_set_master (net/core/rtnetlink.c:2917)\ndo_setlink.isra.0 (net/core/rtnetlink.c:3117)",
"id": "GHSA-3fpr-88w3-v99m",
"modified": "2026-05-12T15:30:50Z",
"published": "2025-03-06T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58071"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a7794b9ca78c8e7d001c583bf05736169de3f20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/184a564e6000b41582f160a5be9a9b5aabe22ac1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bb06f919fa5bec77ad9b6002525c3dcc5c1fd6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fff5da4ca2164bb4d0f1e6cd33f6eb8a0e73e50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62ff1615815d565448c37cb8a7a2a076492ec471"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adff6ac889e16d97abd1e4543f533221127e978a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd099a2fa9be983ba0e90a57a59484fe9d520ba8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9bce1310c0e2a55888e3e08c9f69d8377b3a377"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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-3GFC-6FJV-PJ6M
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-11-25 18:32In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid deadlock in fs reclaim with page writeback
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like:
CPU0 CPU1
ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever
Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.
{
"affected": [],
"aliases": [
"CVE-2023-53149"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T14:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid deadlock in fs reclaim with page writeback\n\nExt4 has a filesystem wide lock protecting ext4_writepages() calls to\navoid races with switching of journalled data flag or inode format. This\nlock can however cause a deadlock like:\n\nCPU0 CPU1\n\next4_writepages()\n percpu_down_read(sbi-\u003es_writepages_rwsem);\n ext4_change_inode_journal_flag()\n percpu_down_write(sbi-\u003es_writepages_rwsem);\n - blocks, all readers block from now on\n ext4_do_writepages()\n ext4_init_io_end()\n kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)\n fs_reclaim frees dentry...\n dentry_unlink_inode()\n iput() - last ref =\u003e\n iput_final() - inode dirty =\u003e\n write_inode_now()...\n ext4_writepages() tries to acquire sbi-\u003es_writepages_rwsem\n and blocks forever\n\nMake sure we cannot recurse into filesystem reclaim from writeback code\nto avoid the deadlock.",
"id": "GHSA-3gfc-6fjv-pj6m",
"modified": "2025-11-25T18:32:21Z",
"published": "2025-09-15T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53149"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00d873c17e29cc32d90ca852b82685f1673acaa5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ec97dc90df40c50e509809dc9a198638a7e18b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b4340bf04ce9a52061f15000ecedd126abc093c"
}
],
"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-3H59-8483-H44F
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 18:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: Fix deadlocks with kctl removals at disconnection
In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely:
-
A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem.
-
The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks.
An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again.
So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now.
{
"affected": [],
"aliases": [
"CVE-2024-38600"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: Fix deadlocks with kctl removals at disconnection\n\nIn snd_card_disconnect(), we set card-\u003eshutdown flag at the beginning,\ncall callbacks and do sync for card-\u003epower_ref_sleep waiters at the\nend. The callback may delete a kctl element, and this can lead to a\ndeadlock when the device was in the suspended state. Namely:\n\n* A process waits for the power up at snd_power_ref_and_wait() in\n snd_ctl_info() or read/write() inside card-\u003econtrols_rwsem.\n\n* The system gets disconnected meanwhile, and the driver tries to\n delete a kctl via snd_ctl_remove*(); it tries to take\n card-\u003econtrols_rwsem again, but this is already locked by the\n above. Since the sleeper isn\u0027t woken up, this deadlocks.\n\nAn easy fix is to wake up sleepers before processing the driver\ndisconnect callbacks but right after setting the card-\u003eshutdown flag.\nThen all sleepers will abort immediately, and the code flows again.\n\nSo, basically this patch moves the wait_event() call at the right\ntiming. While we\u0027re at it, just to be sure, call wait_event_all()\ninstead of wait_event(), although we don\u0027t use exclusive events on\nthis queue for now.",
"id": "GHSA-3h59-8483-h44f",
"modified": "2024-08-27T18:31:35Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38600"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7"
}
],
"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-3HG2-R75X-G69M
Vulnerability from github – Published: 2023-09-18 19:20 – Updated: 2024-11-22 20:35Impact
Locks of the type @nonreentrant("") or @nonreentrant('') do not produce reentrancy checks at runtime.
@nonreentrant("") # unprotected
@external
def bar():
pass
@nonreentrant("lock") # protected
@external
def foo():
pass
Patches
Patched in #3605
Workarounds
The lock name should be a non-empty string.
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.9"
},
{
"fixed": "0.3.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-42441"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-18T19:20:55Z",
"nvd_published_at": "2023-09-18T21:16:09Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nLocks of the type `@nonreentrant(\"\")` or `@nonreentrant(\u0027\u0027)` do not produce reentrancy checks at runtime.\n\n```Vyper\n@nonreentrant(\"\") # unprotected\n@external\ndef bar():\n pass\n\n@nonreentrant(\"lock\") # protected\n@external\ndef foo():\n pass\n```\n### Patches\n\nPatched in #3605\n\n### Workarounds\n\nThe lock name should be a non-empty string.\n\n### References\n_Are there any links users can visit to find out more?_\n",
"id": "GHSA-3hg2-r75x-g69m",
"modified": "2024-11-22T20:35:07Z",
"published": "2023-09-18T19:20:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-3hg2-r75x-g69m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42441"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/pull/3605"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/0b740280c1e3c5528a20d47b29831948ddcc6d83"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-305.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 has incorrect re-entrancy lock when key is empty string"
}
GHSA-3HJ2-HH36-HV9V
Vulnerability from github – Published: 2021-08-25 20:51 – Updated: 2023-06-13 22:11In the affected versions of this crate, Demuxer unconditionally implemented Send with no trait bounds on T. This allows sending a non-Send type T across thread boundaries, which can cause undefined behavior like unlocking a mutex from a thread that didn't lock the mutex, or memory corruption from data race. The flaw was corrected in commit 0562cbf by adding a T: Send bound to the Send impl for Demuxer.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "va-ts"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36220"
],
"database_specific": {
"cwe_ids": [
"CWE-662",
"CWE-667",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T18:47:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "In the affected versions of this crate, Demuxer\u003cT\u003e unconditionally implemented Send with no trait bounds on T. This allows sending a non-Send type T across thread boundaries, which can cause undefined behavior like unlocking a mutex from a thread that didn\u0027t lock the mutex, or memory corruption from data race. The flaw was corrected in commit `0562cbf` by adding a T: Send bound to the Send impl for Demuxer\u003cT\u003e.",
"id": "GHSA-3hj2-hh36-hv9v",
"modified": "2023-06-13T22:11:43Z",
"published": "2021-08-25T20:51:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36220"
},
{
"type": "WEB",
"url": "https://github.com/video-audio/va-ts/issues/4"
},
{
"type": "PACKAGE",
"url": "https://github.com/video-audio/va-ts"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0114.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Data race in va-ts"
}
GHSA-3HJ7-RW79-JH5M
Vulnerability from github – Published: 2025-10-28 09:31 – Updated: 2025-10-28 09:31Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects
smartLink HW-PN: from 1.02 through 1.03
smartLink HW-DP: 1.31
{
"affected": [],
"aliases": [
"CVE-2025-10151"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-28T08:15:32Z",
"severity": "HIGH"
},
"details": "Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects\n\nsmartLink HW-PN: from 1.02 through 1.03\n\nsmartLink HW-DP: 1.31",
"id": "GHSA-3hj7-rw79-jh5m",
"modified": "2025-10-28T09:31:54Z",
"published": "2025-10-28T09:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10151"
},
{
"type": "WEB",
"url": "https://https://industrial.softing.com/fileadmin/psirt/downloads/2025/CVE-2025-10151.html"
},
{
"type": "WEB",
"url": "https://https://industrial.softing.com/fileadmin/psirt/downloads/2025/CVE-2025-10151.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
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.