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-6W9W-8G4V-J4M6
Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2025-04-14 18:31An issue was discovered in illumos before f859e7171bb5db34321e45585839c6c3200ebb90, OmniOS Community Edition r151038, OpenIndiana Hipster 2021.04, and SmartOS 20210923. A local unprivileged user can cause a deadlock and kernel panic via crafted rename and rmdir calls on tmpfs filesystems. Oracle Solaris 10 and 11 is also affected.
{
"affected": [],
"aliases": [
"CVE-2021-43395"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-26T06:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in illumos before f859e7171bb5db34321e45585839c6c3200ebb90, OmniOS Community Edition r151038, OpenIndiana Hipster 2021.04, and SmartOS 20210923. A local unprivileged user can cause a deadlock and kernel panic via crafted rename and rmdir calls on tmpfs filesystems. Oracle Solaris 10 and 11 is also affected.",
"id": "GHSA-6w9w-8g4v-j4m6",
"modified": "2025-04-14T18:31:42Z",
"published": "2022-12-26T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43395"
},
{
"type": "WEB",
"url": "https://github.com/illumos/illumos-gate/commit/f859e7171bb5db34321e45585839c6c3200ebb90"
},
{
"type": "WEB",
"url": "https://github.com/illumos/illumos-gate/blob/069654420de4aade43c63c43cd2896e66945fc8a/usr/src/uts/common/fs/tmpfs/tmp_vnops.c"
},
{
"type": "WEB",
"url": "https://github.com/illumos/illumos-gate/blob/b3403853e80914bd0aade9b5b605da4878078173/usr/src/uts/common/fs/tmpfs/tmp_dir.c"
},
{
"type": "WEB",
"url": "https://illumos.topicbox.com/groups/developer/T1c9e4f27f8c2f959/security-heads-up-illumos14424"
},
{
"type": "WEB",
"url": "https://jgardner100.wordpress.com/2022/01/20/security-heads-up"
},
{
"type": "WEB",
"url": "https://kebe.com/blog/?p=505"
},
{
"type": "WEB",
"url": "https://www.illumos.org/issues/14424"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "http://www.tribblix.org/relnotes.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-6WQ5-2J9J-6RVR
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.
The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.
Reported-and-tested by: Yue Sun samsun1006219@gmail.com Reported by: xingwei lee xrivendell7@gmail.com
{
"affected": [],
"aliases": [
"CVE-2024-26934"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:08Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix deadlock in usb_deauthorize_interface()\n\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0027s parent\nUSB device.\n\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can\u0027t complete\nuntil the device lock has been released, and the lock won\u0027t be\nreleased until the removal has finished.\n\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\n\nReported-and-tested by: Yue Sun \u003csamsun1006219@gmail.com\u003e\nReported by: xingwei lee \u003cxrivendell7@gmail.com\u003e",
"id": "GHSA-6wq5-2j9j-6rvr",
"modified": "2026-05-12T12:31:42Z",
"published": "2024-05-01T06:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6WX8-W4F5-WWCR
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47Summary
Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.
Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError.
This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
release_write_lock checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:
def release_write_lock
return true unless running_writer?
c = @Counter.update { |counter| counter - RUNNING_WRITER }
@ReadLock.broadcast
@WriteLock.signal if waiting_writers(c) > 0
true
end
Because ownership is not checked, a different thread can clear the RUNNING_WRITER bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.
release_read_lock unconditionally decrements the shared counter:
def release_read_lock
while true
c = @Counter.value
if @Counter.compare_and_set(c, c-1)
if waiting_writer?(c) && running_readers(c) == 1
@WriteLock.signal
end
break
end
end
true
end
On a fresh lock, this changes the counter from 0 to -1. A later acquire_read_lock raises Concurrent::ResourceLimitError because the maximum-reader check masks the negative counter as saturated.
Reproduce
From the root of a concurrent-ruby checkout, run:
ruby -Ilib/concurrent-ruby - <<'RUBY'
require 'concurrent/atomic/read_write_lock'
require 'concurrent/version'
require 'thread'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReadWriteLock release methods corrupt or bypass lock state"
lock = Concurrent::ReadWriteLock.new
events = Queue.new
writer1_inside = false
writer1 = Thread.new do
lock.acquire_write_lock
writer1_inside = true
events << :writer1_acquired
sleep 0.5
writer1_inside = false
lock.release_write_lock
events << :writer1_finished
end
events.pop
puts 'writer1_acquired=true'
intruder_result = nil
intruder = Thread.new do
intruder_result = lock.release_write_lock
end
intruder.join
puts "wrong_thread_release_write_lock_returned=#{intruder_result}"
writer2_entered_while_writer1_inside = nil
writer2 = Thread.new do
lock.acquire_write_lock
writer2_entered_while_writer1_inside = writer1_inside
lock.release_write_lock
end
writer2.join(0.25)
puts "writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}"
writer1.join
lock2 = Concurrent::ReadWriteLock.new
stray_read_release_result = lock2.release_read_lock
counter_after_stray_read_release = lock2.instance_eval { @Counter.value }
read_after_stray_release = begin
lock2.acquire_read_lock
'acquired'
rescue => error
"#{error.class}: #{error.message}"
end
puts "stray_release_read_lock_returned=#{stray_read_release_result}"
puts "counter_after_stray_read_release=#{counter_after_stray_read_release}"
puts "acquire_read_after_stray_release=#{read_after_stray_release}"
if intruder_result && writer2_entered_while_writer1_inside && counter_after_stray_read_release == -1
puts 'result=REPRODUCED wrong-thread write release and stray read-release corruption'
else
puts 'result=NOT_REPRODUCED'
end
Expected result:
- A second thread successfully calls
release_write_lockwhile the first writer still holds the lock. - A second writer enters while the first writer is still inside the write critical section.
- Calling
release_read_lockon a fresh lock changes the counter to-1. - A subsequent read acquisition fails with
Concurrent::ResourceLimitError.
Log evidence
Local reproduction output:
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReadWriteLock release methods corrupt or bypass lock state
writer1_acquired=true
wrong_thread_release_write_lock_returned=true
writer2_acquired_while_writer1_inside=true
stray_release_read_lock_returned=true
counter_after_stray_read_release=-1
acquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads
result=REPRODUCED wrong-thread write release and stray read-release corruption
Impact
This can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.
The impact is local to applications that expose or misuse the manual acquire_* / release_* APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "concurrent-ruby"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54906"
],
"database_specific": {
"cwe_ids": [
"CWE-414",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:41Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n`Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.\n\n`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.\n\nThis is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n\n### Details\n\n`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:\n\n```ruby\ndef release_write_lock\n return true unless running_writer?\n c = @Counter.update { |counter| counter - RUNNING_WRITER }\n @ReadLock.broadcast\n @WriteLock.signal if waiting_writers(c) \u003e 0\n true\nend\n```\n\nBecause ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.\n\n`release_read_lock` unconditionally decrements the shared counter:\n\n```ruby\ndef release_read_lock\n while true\n c = @Counter.value\n if @Counter.compare_and_set(c, c-1)\n if waiting_writer?(c) \u0026\u0026 running_readers(c) == 1\n @WriteLock.signal\n end\n break\n end\n end\n true\nend\n```\n\nOn a fresh lock, this changes the counter from `0` to `-1`. A later `acquire_read_lock` raises `Concurrent::ResourceLimitError` because the maximum-reader check masks the negative counter as saturated.\n\n# Reproduce\n\nFrom the root of a `concurrent-ruby` checkout, run:\n\n```bash\nruby -Ilib/concurrent-ruby - \u003c\u003c\u0027RUBY\u0027\nrequire \u0027concurrent/atomic/read_write_lock\u0027\nrequire \u0027concurrent/version\u0027\nrequire \u0027thread\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=ReadWriteLock release methods corrupt or bypass lock state\"\n\nlock = Concurrent::ReadWriteLock.new\nevents = Queue.new\nwriter1_inside = false\n\nwriter1 = Thread.new do\n lock.acquire_write_lock\n writer1_inside = true\n events \u003c\u003c :writer1_acquired\n sleep 0.5\n writer1_inside = false\n lock.release_write_lock\n events \u003c\u003c :writer1_finished\nend\n\nevents.pop\nputs \u0027writer1_acquired=true\u0027\n\nintruder_result = nil\nintruder = Thread.new do\n intruder_result = lock.release_write_lock\nend\nintruder.join\n\nputs \"wrong_thread_release_write_lock_returned=#{intruder_result}\"\n\nwriter2_entered_while_writer1_inside = nil\nwriter2 = Thread.new do\n lock.acquire_write_lock\n writer2_entered_while_writer1_inside = writer1_inside\n lock.release_write_lock\nend\n\nwriter2.join(0.25)\n\nputs \"writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}\"\n\nwriter1.join\n\nlock2 = Concurrent::ReadWriteLock.new\nstray_read_release_result = lock2.release_read_lock\ncounter_after_stray_read_release = lock2.instance_eval { @Counter.value }\nread_after_stray_release = begin\n lock2.acquire_read_lock\n \u0027acquired\u0027\nrescue =\u003e error\n \"#{error.class}: #{error.message}\"\nend\n\nputs \"stray_release_read_lock_returned=#{stray_read_release_result}\"\nputs \"counter_after_stray_read_release=#{counter_after_stray_read_release}\"\nputs \"acquire_read_after_stray_release=#{read_after_stray_release}\"\n\nif intruder_result \u0026\u0026 writer2_entered_while_writer1_inside \u0026\u0026 counter_after_stray_read_release == -1\n puts \u0027result=REPRODUCED wrong-thread write release and stray read-release corruption\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n```\nExpected result:\n\n- A second thread successfully calls `release_write_lock` while the first writer still holds the lock.\n- A second writer enters while the first writer is still inside the write critical section.\n- Calling `release_read_lock` on a fresh lock changes the counter to `-1`.\n- A subsequent read acquisition fails with `Concurrent::ResourceLimitError`.\n\n### Log evidence\n\nLocal reproduction output:\n\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=ReadWriteLock release methods corrupt or bypass lock state\nwriter1_acquired=true\nwrong_thread_release_write_lock_returned=true\nwriter2_acquired_while_writer1_inside=true\nstray_release_read_lock_returned=true\ncounter_after_stray_read_release=-1\nacquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads\nresult=REPRODUCED wrong-thread write release and stray read-release corruption\n```\n\n### Impact\nThis can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.\nThe impact is local to applications that expose or misuse the manual `acquire_*` / `release_*` APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "GHSA-6wx8-w4f5-wwcr",
"modified": "2026-06-19T20:47:41Z",
"published": "2026-06-19T20:47:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption"
}
GHSA-72W6-32C7-VF7P
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ublk: fix deadlock when reading partition table
When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur:
- bdev_open() grabs disk->open_mutex
- The process issues read I/O to ublk backend to read partition table
- In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks
- If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation)
- This eventually calls blkdev_release() from the same context
- blkdev_release() tries to grab disk->open_mutex again
- Deadlock: same task waiting for a mutex it already holds
The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock.
[axboe: rewrite comment in ublk]
{
"affected": [],
"aliases": [
"CVE-2025-68823"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix deadlock when reading partition table\n\nWhen one process(such as udev) opens ublk block device (e.g., to read\nthe partition table via bdev_open()), a deadlock[1] can occur:\n\n1. bdev_open() grabs disk-\u003eopen_mutex\n2. The process issues read I/O to ublk backend to read partition table\n3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()\n runs bio-\u003ebi_end_io() callbacks\n4. If this triggers fput() on file descriptor of ublk block device, the\n work may be deferred to current task\u0027s task work (see fput() implementation)\n5. This eventually calls blkdev_release() from the same context\n6. blkdev_release() tries to grab disk-\u003eopen_mutex again\n7. Deadlock: same task waiting for a mutex it already holds\n\nThe fix is to run blk_update_request() and blk_mq_end_request() with bottom\nhalves disabled. This forces blkdev_release() to run in kernel work-queue\ncontext instead of current task work context, and allows ublk server to make\nforward progress, and avoids the deadlock.\n\n[axboe: rewrite comment in ublk]",
"id": "GHSA-72w6-32c7-vf7p",
"modified": "2026-06-01T18:31:21Z",
"published": "2026-01-13T18:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68823"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0460e09a614291f06c008443f47393c37b7358e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27bb79b7717b2fbb111a1c13548b2786ee712dca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64c0b7e2293757e8320f13434cd809f1c9257a62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bcc47343ee0ef346aa7b2b460c8ff56bd882fe7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c258f5c4502c9667bccf5d76fa731ab9c96687c1"
}
],
"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-73J2-7869-745F
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-17 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix locking order in ivpu_job_submit
Fix deadlock in job submission and abort handling. When a thread aborts currently executing jobs due to a fault, it first locks the global lock protecting submitted_jobs (#1).
After the last job is destroyed, it proceeds to release the related context and locks file_priv (#2). Meanwhile, in the job submission thread, the file_priv lock (#2) is taken first, and then the submitted_jobs lock (#1) is obtained when a job is added to the submitted jobs list.
CPU0 CPU1
---- ----
(for example due to a fault) (jobs submissions keep coming)
lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2
This order of locking causes a deadlock. To resolve this issue, change the order of locking in ivpu_job_submit().
{
"affected": [],
"aliases": [
"CVE-2025-37907"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix locking order in ivpu_job_submit\n\nFix deadlock in job submission and abort handling.\nWhen a thread aborts currently executing jobs due to a fault,\nit first locks the global lock protecting submitted_jobs (#1).\n\nAfter the last job is destroyed, it proceeds to release the related context\nand locks file_priv (#2). Meanwhile, in the job submission thread,\nthe file_priv lock (#2) is taken first, and then the submitted_jobs\nlock (#1) is obtained when a job is added to the submitted jobs list.\n\n CPU0 CPU1\n ---- \t ----\n (for example due to a fault) (jobs submissions keep coming)\n\n lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n ivpu_jobs_abort_all()\n job_destroy()\n lock(\u0026file_priv-\u003elock) #2\n lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n file_priv_release()\n lock(\u0026vdev-\u003econtext_list_lock)\n lock(\u0026file_priv-\u003elock) #2\n\nThis order of locking causes a deadlock. To resolve this issue,\nchange the order of locking in ivpu_job_submit().",
"id": "GHSA-73j2-7869-745f",
"modified": "2025-11-17T15:30:31Z",
"published": "2025-05-20T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37907"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab680dc6c78aa035e944ecc8c48a1caab9f39924"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b70924a272c2d72023306bc56f521c056212ee"
}
],
"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-752V-R57R-J98P
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/pci: Fix get_phb_number() locking
The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP warning on some systems:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64
This is because pcibios_alloc_controller() holds hose_spinlock but of_alias_get_id() takes of_mutex which can sleep.
The hose_spinlock protects the phb_bitmap, and also the hose_list, but it doesn't need to be held while get_phb_number() calls the OF routines, because those are only looking up information in the device tree.
So fix it by having get_phb_number() take the hose_spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs to take the lock again before the list_add() but that's safe, the order of the list is not important.
{
"affected": [],
"aliases": [
"CVE-2022-50045"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pci: Fix get_phb_number() locking\n\nThe recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP\nwarning on some systems:\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n 1 lock held by swapper/1:\n #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220\n Preemption disabled at:\n [\u003c00000000\u003e] 0x0\n CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1\n Call Trace:\n [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)\n [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8\n [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec\n [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4\n [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220\n [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784\n [d101de50] [c140852c] discover_phbs+0x30/0x4c\n [d101de60] [c0007fd4] do_one_initcall+0x94/0x344\n [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c\n [d101df10] [c00086e0] kernel_init+0x34/0x160\n [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64\n\nThis is because pcibios_alloc_controller() holds hose_spinlock but\nof_alias_get_id() takes of_mutex which can sleep.\n\nThe hose_spinlock protects the phb_bitmap, and also the hose_list, but\nit doesn\u0027t need to be held while get_phb_number() calls the OF routines,\nbecause those are only looking up information in the device tree.\n\nSo fix it by having get_phb_number() take the hose_spinlock itself, only\nwhere required, and then dropping the lock before returning.\npcibios_alloc_controller() then needs to take the lock again before the\nlist_add() but that\u0027s safe, the order of the list is not important.",
"id": "GHSA-752v-r57r-j98p",
"modified": "2025-11-13T21:31:18Z",
"published": "2025-06-18T12:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50045"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d9e75c3d8cdf7c96a94cb77450d4ee070279e6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5db5ce0f1963c6c8275719a80cb65e9c98d32726"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f75057c21eab12c6ccb7f06f859641a6edfab99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d48562a2729742f767b0fdd994d6b2a56a49c63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90f195c01a2e8d8da6281791617e21109719c981"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a868f771ee41c97a25a04b8c632a7f06689b307b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ccb0a42d3f40c436295e0fef57ab613ae5b925a4"
}
],
"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-75HW-9685-7HFF
Vulnerability from github – Published: 2023-12-08 21:30 – Updated: 2025-11-04 21:30Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412 where software, under certain circumstances, could deadlock a core due to the execution of either a load to device or non-cacheable memory, and either a store exclusive or register read of the Physical Address Register (PAR_EL1) in close proximity.
{
"affected": [],
"aliases": [
"CVE-2023-34320"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-08T21:15:07Z",
"severity": "MODERATE"
},
"details": "Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412\nwhere software, under certain circumstances, could deadlock a core\ndue to the execution of either a load to device or non-cacheable memory,\nand either a store exclusive or register read of the Physical\nAddress Register (PAR_EL1) in close proximity.",
"id": "GHSA-75hw-9685-7hff",
"modified": "2025-11-04T21:30:50Z",
"published": "2023-12-08T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34320"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-436.html"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-436.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-75WM-6772-RQF5
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31A lock screen issue allowed access to messages on a locked device. This issue was addressed with improved state management. This issue is fixed in iOS 14.0 and iPadOS 14.0. A person with physical access to an iOS device may be able to view notification contents from the lockscreen.
{
"affected": [],
"aliases": [
"CVE-2020-9959"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T17:15:00Z",
"severity": "LOW"
},
"details": "A lock screen issue allowed access to messages on a locked device. This issue was addressed with improved state management. This issue is fixed in iOS 14.0 and iPadOS 14.0. A person with physical access to an iOS device may be able to view notification contents from the lockscreen.",
"id": "GHSA-75wm-6772-rqf5",
"modified": "2022-05-24T17:31:11Z",
"published": "2022-05-24T17:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9959"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211850"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-762P-XX25-G6MQ
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
Revert "sched/fair: Make sure to try to detach at least one movable task"
This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.
b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu.
When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue.
{
"affected": [],
"aliases": [
"CVE-2024-42245"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T16:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"sched/fair: Make sure to try to detach at least one movable task\"\n\nThis reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.\n\nb0defa7ae03ec changed the load balancing logic to ignore env.max_loop if\nall tasks examined to that point were pinned. The goal of the patch was\nto make it more likely to be able to detach a task buried in a long list\nof pinned tasks. However, this has the unfortunate side effect of\ncreating an O(n) iteration in detach_tasks(), as we now must fully\niterate every task on a cpu if all or most are pinned. Since this load\nbalance code is done with rq lock held, and often in softirq context, it\nis very easy to trigger hard lockups. We observed such hard lockups with\na user who affined O(10k) threads to a single cpu.\n\nWhen I discussed this with Vincent he initially suggested that we keep\nthe limit on the number of tasks to detach, but increase the number of\ntasks we can search. However, after some back and forth on the mailing\nlist, he recommended we instead revert the original patch, as it seems\nlikely no one was actually getting hit by the original issue.",
"id": "GHSA-762p-xx25-g6mq",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-07T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42245"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d467194018dd536fe6c65a2fd3aedfcdb1424903"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-76F2-QJ4M-VMQR
Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2024-10-01 18:31In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting.
{
"affected": [],
"aliases": [
"CVE-2024-46868"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-27T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()\n\nIf the __qcuefi pointer is not set, then in the original code, we would\nhold onto the lock. That means that if we tried to set it later, then\nit would cause a deadlock. Drop the lock on the error path. That\u0027s\nwhat all the callers are expecting.",
"id": "GHSA-76f2-qj4m-vmqr",
"modified": "2024-10-01T18:31:17Z",
"published": "2024-09-27T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6a5a1fc02ad1d62d06897ab330693d4d27cd03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db213b0cfe3268d8b1d382b3bcc999c687a2567f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.