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-HR22-G233-2GJG
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-05-14 15:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()
l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock.
Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().
{
"affected": [],
"aliases": [
"CVE-2026-31499"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix deadlock in l2cap_conn_del()\n\nl2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer\nand id_addr_timer while holding conn-\u003elock. However, the work functions\nl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire\nconn-\u003elock, creating a potential AB-BA deadlock if the work is already\nexecuting when l2cap_conn_del() takes the lock.\n\nMove the work cancellations before acquiring conn-\u003elock and use\ndisable_delayed_work_sync() to additionally prevent the works from\nbeing rearmed after cancellation, consistent with the pattern used in\nhci_conn_del().",
"id": "GHSA-hr22-g233-2gjg",
"modified": "2026-05-14T15:31:51Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31499"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00fdebbbc557a2fc21321ff2eaa22fd70c078608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f26ecbd9cde621dd94be7ef252c7210b965a5c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d008460de352e534f6721de829b093368564ec66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7f35a4f7fd574f5889bb2e4b397e14cbb83f6da"
}
],
"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-HRH9-752P-34VJ
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2024-10-22 18:32In the Linux kernel, the following vulnerability has been resolved:
KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock
Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores).
CPU0 CPU1 CPU2
1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu);
Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier():
cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier()
But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual.
The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list.
====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O
tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]
but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0
---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-47744"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock\n\nUse a dedicated mutex to guard kvm_usage_count to fix a potential deadlock\non x86 due to a chain of locks and SRCU synchronizations. Translating the\nbelow lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on\nCPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there\u0027s a writer, due to the\nfairness of r/w semaphores).\n\n CPU0 CPU1 CPU2\n1 lock(\u0026kvm-\u003eslots_lock);\n2 lock(\u0026vcpu-\u003emutex);\n3 lock(\u0026kvm-\u003esrcu);\n4 lock(cpu_hotplug_lock);\n5 lock(kvm_lock);\n6 lock(\u0026kvm-\u003eslots_lock);\n7 lock(cpu_hotplug_lock);\n8 sync(\u0026kvm-\u003esrcu);\n\nNote, there are likely more potential deadlocks in KVM x86, e.g. the same\npattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with\n__kvmclock_cpufreq_notifier():\n\n cpuhp_cpufreq_online()\n |\n -\u003e cpufreq_online()\n |\n -\u003e cpufreq_gov_performance_limits()\n |\n -\u003e __cpufreq_driver_target()\n |\n -\u003e __target_index()\n |\n -\u003e cpufreq_freq_transition_begin()\n |\n -\u003e cpufreq_notify_transition()\n |\n -\u003e ... __kvmclock_cpufreq_notifier()\n\nBut, actually triggering such deadlocks is beyond rare due to the\ncombination of dependencies and timings involved. E.g. the cpufreq\nnotifier is only used on older CPUs without a constant TSC, mucking with\nthe NX hugepage mitigation while VMs are running is very uncommon, and\ndoing so while also onlining/offlining a CPU (necessary to generate\ncontention on cpu_hotplug_lock) would be even more unusual.\n\nThe most robust solution to the general cpu_hotplug_lock issue is likely\nto switch vm_list to be an RCU-protected list, e.g. so that x86\u0027s cpufreq\nnotifier doesn\u0027t to take kvm_lock. For now, settle for fixing the most\nblatant deadlock, as switching to an RCU-protected list is a much more\ninvolved change, but add a comment in locking.rst to call out that care\nneeds to be taken when walking holding kvm_lock and walking vm_list.\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O\n ------------------------------------------------------\n tee/35048 is trying to acquire lock:\n ff6a80eced71e0a8 (\u0026kvm-\u003eslots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]\n\n but task is already holding lock:\n ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #3 (kvm_lock){+.+.}-{3:3}:\n __mutex_lock+0x6a/0xb40\n mutex_lock_nested+0x1f/0x30\n kvm_dev_ioctl+0x4fb/0xe50 [kvm]\n __se_sys_ioctl+0x7b/0xd0\n __x64_sys_ioctl+0x21/0x30\n x64_sys_call+0x15d0/0x2e60\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #2 (cpu_hotplug_lock){++++}-{0:0}:\n cpus_read_lock+0x2e/0xb0\n static_key_slow_inc+0x16/0x30\n kvm_lapic_set_base+0x6a/0x1c0 [kvm]\n kvm_set_apic_base+0x8f/0xe0 [kvm]\n kvm_set_msr_common+0x9ae/0xf80 [kvm]\n vmx_set_msr+0xa54/0xbe0 [kvm_intel]\n __kvm_set_msr+0xb6/0x1a0 [kvm]\n kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]\n kvm_vcpu_ioctl+0x485/0x5b0 [kvm]\n __se_sys_ioctl+0x7b/0xd0\n __x64_sys_ioctl+0x21/0x30\n x64_sys_call+0x15d0/0x2e60\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #1 (\u0026kvm-\u003esrcu){.+.+}-{0:0}:\n __synchronize_srcu+0x44/0x1a0\n \n---truncated---",
"id": "GHSA-hrh9-752p-34vj",
"modified": "2024-10-22T18:32:09Z",
"published": "2024-10-21T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47744"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44d17459626052a2390457e550a12cb973506b2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4777225ec89f52bb9ca16a33cfb44c189f1b7b47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/760a196e6dcb29580e468b44b5400171dae184d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2764afce521fd9fd7a5ff6ed52ac2095873128a"
}
],
"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-HWG2-2RXQ-2XM4
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54An issue was discovered in OpenWrt libuci (aka Library for the Unified Configuration Interface) as used on Motorola CX2L MWR04L 1.01 and C1 MWR03 1.01 devices. /tmp/.uci/network locking is mishandled after reception of a long SetWanSettings command, leading to a device hang.
{
"affected": [],
"aliases": [
"CVE-2019-15513"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T07:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in OpenWrt libuci (aka Library for the Unified Configuration Interface) as used on Motorola CX2L MWR04L 1.01 and C1 MWR03 1.01 devices. /tmp/.uci/network locking is mishandled after reception of a long SetWanSettings command, leading to a device hang.",
"id": "GHSA-hwg2-2rxq-2xm4",
"modified": "2022-05-24T16:54:40Z",
"published": "2022-05-24T16:54:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15513"
},
{
"type": "WEB",
"url": "https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=19e29ffc15dbd958e8e6a648ee0982c68353516f"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/blob/master/iot/morouter/motorola%E8%B7%AF%E7%94%B1%E5%99%A8%E6%96%87%E4%BB%B6%E8%A7%A3%E9%94%81%E6%BC%8F%E6%B4%9E.pdf"
},
{
"type": "WEB",
"url": "https://lists.infradead.org/pipermail/openwrt-devel/2019-November/019736.html"
},
{
"type": "WEB",
"url": "https://lists.openwrt.org/pipermail/openwrt-devel/2019-November/025453.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HWGV-6MJR-CW48
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2025-11-04 18:30In the Linux kernel, the following vulnerability has been resolved:
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below.
A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.
{
"affected": [],
"aliases": [
"CVE-2024-26999"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\n\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0027re using pmac_zilog as a serial console:\n\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\n\nThat\u0027s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\n\nEven when it\u0027s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0027t play nicely with QEMU, as can be\nseen in the bug report linked below.\n\nA web search for other reports of the error message \"pmz: rx irq flood\"\ndidn\u0027t produce anything. So I don\u0027t think this code is needed any more.\nRemove it.",
"id": "GHSA-hwgv-6mjr-cw48",
"modified": "2025-11-04T18:30:51Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26999"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1be3226445362bfbf461c92a5bcdb1723f2e4907"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c575a729"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-HX2R-XG86-XJ35
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
spi: Fix deadlock when adding SPI controllers on SPI buses
Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.
{
"affected": [],
"aliases": [
"CVE-2021-47469"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T07:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: Fix deadlock when adding SPI controllers on SPI buses\n\nCurrently we have a global spi_add_lock which we take when adding new\ndevices so that we can check that we\u0027re not trying to reuse a chip\nselect that\u0027s already controlled. This means that if the SPI device is\nitself a SPI controller and triggers the instantiation of further SPI\ndevices we trigger a deadlock as we try to register and instantiate\nthose devices while in the process of doing so for the parent controller\nand hence already holding the global spi_add_lock. Since we only care\nabout concurrency within a single SPI bus move the lock to be per\ncontroller, avoiding the deadlock.\n\nThis can be easily triggered in the case of spi-mux.",
"id": "GHSA-hx2r-xg86-xj35",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-22T09:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47469"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6098475d4cb48d821bdf453c61118c56e26294f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/722ef19a161ce3fffb3d1b01ce2301c306639bdd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa3f3d7bef59583f2d3234173105a27ff61ef8fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8dce228db6f81dbc897a018dfc5c418e917cf64"
}
],
"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-HX5F-FXHR-8P95
Vulnerability from github – Published: 2022-08-25 00:00 – Updated: 2022-08-29 20:06A memory corruption vulnerability was addressed with improved locking. This issue is fixed in macOS Monterey 12.5, macOS Big Sur 11.6.8, Security Update 2022-005 Catalina. An app may be able to execute arbitrary code with kernel privileges.
{
"affected": [],
"aliases": [
"CVE-2022-32811"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-24T20:15:00Z",
"severity": "HIGH"
},
"details": "A memory corruption vulnerability was addressed with improved locking. This issue is fixed in macOS Monterey 12.5, macOS Big Sur 11.6.8, Security Update 2022-005 Catalina. An app may be able to execute arbitrary code with kernel privileges.",
"id": "GHSA-hx5f-fxhr-8p95",
"modified": "2022-08-29T20:06:55Z",
"published": "2022-08-25T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32811"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213343"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213344"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213345"
}
],
"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-HX7P-6FCF-8GXF
Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-06-03 18:53In the Linux kernel, the following vulnerability has been resolved:
cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that cpuset_attach() is also called from cgroup_attach_task_all(). Add cpus_read_lock() like what cgroup_procs_write_start() does.
{
"affected": [],
"aliases": [
"CVE-2022-48671"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T15:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()\n\nsyzbot is hitting percpu_rwsem_assert_held(\u0026cpu_hotplug_lock) warning at\ncpuset_attach() [1], for commit 4f7e7236435ca0ab (\"cgroup: Fix\nthreadgroup_rwsem \u003c-\u003e cpus_read_lock() deadlock\") missed that\ncpuset_attach() is also called from cgroup_attach_task_all().\nAdd cpus_read_lock() like what cgroup_procs_write_start() does.",
"id": "GHSA-hx7p-6fcf-8gxf",
"modified": "2024-06-03T18:53:45Z",
"published": "2024-05-03T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48671"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07191f984842d50020789ff14c75da436a7f46a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/321488cfac7d0eb6d97de467015ff754f85813ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43626dade36fa74d3329046f4ae2d7fdefe401c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5db17805b6ba4c34dab303f49aea3562fc25af75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99bc25748e394d17f9e8b10cc7f273b8e64c1c7e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f267393b036f1470fb12fb892d59e7ff8aeb58d"
}
],
"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-HXR9-Q428-7JHG
Vulnerability from github – Published: 2024-07-29 15:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix possible deadlock in io_register_iowq_max_workers()
The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before acquiring sqd->lock"), this can lead to a potential deadlock situation.
To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call.
This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-41080"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T15:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix possible deadlock in io_register_iowq_max_workers()\n\nThe io_register_iowq_max_workers() function calls io_put_sq_data(),\nwhich acquires the sqd-\u003elock without releasing the uring_lock.\nSimilar to the commit 009ad9f0c6ee (\"io_uring: drop ctx-\u003euring_lock\nbefore acquiring sqd-\u003elock\"), this can lead to a potential deadlock\nsituation.\n\nTo resolve this issue, the uring_lock is released before calling\nio_put_sq_data(), and then it is re-acquired after the function call.\n\nThis change ensures that the locks are acquired in the correct\norder, preventing the possibility of a deadlock.",
"id": "GHSA-hxr9-q428-7jhg",
"modified": "2025-11-04T00:31:03Z",
"published": "2024-07-29T15:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/950ac86cff338ab56e2eaf611f4936ee34893b63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/97ed7ff58de66c544692b3c2b988f3f594348de0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b17397a0a5c56e111f61cb5b77d162664dc00de9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdacd09f2ddf7a00787291f08ee48c0421e5b709"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J26F-M94F-4HR4
Vulnerability from github – Published: 2022-03-24 00:00 – Updated: 2022-03-31 00:00A vulnerability was found in btrfs_alloc_tree_b in fs/btrfs/extent-tree.c in the Linux kernel due to an improper lock operation in btrfs. In this flaw, a user with a local privilege may cause a denial of service (DOS) due to a deadlock problem.
{
"affected": [],
"aliases": [
"CVE-2021-4149"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-23T20:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in btrfs_alloc_tree_b in fs/btrfs/extent-tree.c in the Linux kernel due to an improper lock operation in btrfs. In this flaw, a user with a local privilege may cause a denial of service (DOS) due to a deadlock problem.",
"id": "GHSA-j26f-m94f-4hr4",
"modified": "2022-03-31T00:00:41Z",
"published": "2022-03-24T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4149"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2026485"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2021/10/18/885"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2021/9/13/2565"
}
],
"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-J2VG-4HPF-83V7
Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2023-02-15 03:30Insufficient policy enforcement in downloads in Google Chrome on Windows prior to 79.0.3945.79 allowed a local attacker to spoof downloaded files via local code.
{
"affected": [],
"aliases": [
"CVE-2019-13762"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-10T22:15:00Z",
"severity": "LOW"
},
"details": "Insufficient policy enforcement in downloads in Google Chrome on Windows prior to 79.0.3945.79 allowed a local attacker to spoof downloaded files via local code.",
"id": "GHSA-j2vg-4hpf-83v7",
"modified": "2023-02-15T03:30:34Z",
"published": "2022-05-24T17:03:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13762"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4238"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1004212"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2Z5M4FPUMDNX2LDPHJKN5ZV5GIS2AKNU"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/N5CIQCVS6E3ULJCNU7YJXJPO2BLQZDTK"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/27"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202003-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4606"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00032.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00036.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"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.