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.
727 vulnerabilities reference this CWE, most recent first.
GHSA-X63M-J7X3-7J84
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-01-08 00:30In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()
syzbot reports deadlock issue of f2fs as below:
====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted
kswapd0/79 is trying to acquire lock: ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068
but task is already holding lock: ffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_internal#2){.+.+}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 percpu_down_read include/linux/percpu-rwsem.h:51 [inline] __sb_start_write include/linux/fs.h:1716 [inline] sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899 f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842 evict+0x4e8/0x9b0 fs/inode.c:725 f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807 evict+0x4e8/0x9b0 fs/inode.c:725 dispose_list fs/inode.c:774 [inline] prune_icache_sb+0x239/0x2f0 fs/inode.c:963 super_cache_scan+0x38c/0x4b0 fs/super.c:223 do_shrink_slab+0x701/0x1160 mm/shrinker.c:435 shrink_slab+0x1093/0x14d0 mm/shrinker.c:662 shrink_one+0x43b/0x850 mm/vmscan.c:4818 shrink_many mm/vmscan.c:4879 [inline] lru_gen_shrink_node mm/vmscan.c:4957 [inline] shrink_node+0x3799/0x3de0 mm/vmscan.c:5937 kswapd_shrink_node mm/vmscan.c:6765 [inline] balance_pgdat mm/vmscan.c:6957 [inline] kswapd+0x1ca3/0x3700 mm/vmscan.c:7226 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
-> #1 (fs_reclaim){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __fs_reclaim_acquire mm/page_alloc.c:3834 [inline] fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848 might_alloc include/linux/sched/mm.h:318 [inline] prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493 __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 alloc_pages_noprof mm/mempolicy.c:2345 [inline] folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352 filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010 do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787 read_mapping_folio include/linux/pagemap.h:1011 [inline] f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032 f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079 f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174 f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785 write_inode fs/fs-writeback.c:1503 [inline] __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723 writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779 sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849 f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:228 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-56744"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()\n\nsyzbot reports deadlock issue of f2fs as below:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted\n------------------------------------------------------\nkswapd0/79 is trying to acquire lock:\nffff888011824088 (\u0026sbi-\u003esb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline]\nffff888011824088 (\u0026sbi-\u003esb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068\n\nbut task is already holding lock:\nffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (sb_internal#2){.+.+}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n percpu_down_read include/linux/percpu-rwsem.h:51 [inline]\n __sb_start_write include/linux/fs.h:1716 [inline]\n sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899\n f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n evict+0x4e8/0x9b0 fs/inode.c:725\n f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807\n evict+0x4e8/0x9b0 fs/inode.c:725\n dispose_list fs/inode.c:774 [inline]\n prune_icache_sb+0x239/0x2f0 fs/inode.c:963\n super_cache_scan+0x38c/0x4b0 fs/super.c:223\n do_shrink_slab+0x701/0x1160 mm/shrinker.c:435\n shrink_slab+0x1093/0x14d0 mm/shrinker.c:662\n shrink_one+0x43b/0x850 mm/vmscan.c:4818\n shrink_many mm/vmscan.c:4879 [inline]\n lru_gen_shrink_node mm/vmscan.c:4957 [inline]\n shrink_node+0x3799/0x3de0 mm/vmscan.c:5937\n kswapd_shrink_node mm/vmscan.c:6765 [inline]\n balance_pgdat mm/vmscan.c:6957 [inline]\n kswapd+0x1ca3/0x3700 mm/vmscan.c:7226\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-\u003e #1 (fs_reclaim){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __fs_reclaim_acquire mm/page_alloc.c:3834 [inline]\n fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848\n might_alloc include/linux/sched/mm.h:318 [inline]\n prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493\n __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722\n alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265\n alloc_pages_noprof mm/mempolicy.c:2345 [inline]\n folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352\n filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010\n do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787\n read_mapping_folio include/linux/pagemap.h:1011 [inline]\n f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032\n f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079\n f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174\n f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785\n write_inode fs/fs-writeback.c:1503 [inline]\n __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723\n writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779\n sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849\n f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:114 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218\n do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n---truncated---",
"id": "GHSA-x63m-j7x3-7j84",
"modified": "2025-01-08T00:30:48Z",
"published": "2024-12-29T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56744"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1539a088b108996bcdaddb7775070b5163b14233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801092a2c9c251ef6a8678fcb8fcc1220474a697"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecf4e6782b01fd578b565b3dd2be7bb0ac91082e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f10a890308a7cd8794e21f646f09827c6cb4bf5d"
}
],
"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-X66G-5578-7PX9
Vulnerability from github – Published: 2024-03-13 15:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep.
First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour.
If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID.
So clearly it is harmful to allow a false positive, which testing so_count allows.
The test is nonsense because ... well... it doesn't mean anything.
so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks.
When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be.
In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail.
In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success.
The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe.
So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'.
{
"affected": [],
"aliases": [
"CVE-2024-26629"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-13T14:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix RELEASE_LOCKOWNER\n\nThe test on so_count in nfsd4_release_lockowner() is nonsense and\nharmful. Revert to using check_for_locks(), changing that to not sleep.\n\nFirst: harmful.\nAs is documented in the kdoc comment for nfsd4_release_lockowner(), the\ntest on so_count can transiently return a false positive resulting in a\nreturn of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is\nclearly a protocol violation and with the Linux NFS client it can cause\nincorrect behaviour.\n\nIf RELEASE_LOCKOWNER is sent while some other thread is still\nprocessing a LOCK request which failed because, at the time that request\nwas received, the given owner held a conflicting lock, then the nfsd\nthread processing that LOCK request can hold a reference (conflock) to\nthe lock owner that causes nfsd4_release_lockowner() to return an\nincorrect error.\n\nThe Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it\nnever sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so\nit knows that the error is impossible. It assumes the lock owner was in\nfact released so it feels free to use the same lock owner identifier in\nsome later locking request.\n\nWhen it does reuse a lock owner identifier for which a previous RELEASE\nfailed, it will naturally use a lock_seqid of zero. However the server,\nwhich didn\u0027t release the lock owner, will expect a larger lock_seqid and\nso will respond with NFS4ERR_BAD_SEQID.\n\nSo clearly it is harmful to allow a false positive, which testing\nso_count allows.\n\nThe test is nonsense because ... well... it doesn\u0027t mean anything.\n\nso_count is the sum of three different counts.\n1/ the set of states listed on so_stateids\n2/ the set of active vfs locks owned by any of those states\n3/ various transient counts such as for conflicting locks.\n\nWhen it is tested against \u00272\u0027 it is clear that one of these is the\ntransient reference obtained by find_lockowner_str_locked(). It is not\nclear what the other one is expected to be.\n\nIn practice, the count is often 2 because there is precisely one state\non so_stateids. If there were more, this would fail.\n\nIn my testing I see two circumstances when RELEASE_LOCKOWNER is called.\nIn one case, CLOSE is called before RELEASE_LOCKOWNER. That results in\nall the lock states being removed, and so the lockowner being discarded\n(it is removed when there are no more references which usually happens\nwhen the lock state is discarded). When nfsd4_release_lockowner() finds\nthat the lock owner doesn\u0027t exist, it returns success.\n\nThe other case shows an so_count of \u00272\u0027 and precisely one state listed\nin so_stateid. It appears that the Linux client uses a separate lock\nowner for each file resulting in one lock state per lock owner, so this\ntest on \u00272\u0027 is safe. For another client it might not be safe.\n\nSo this patch changes check_for_locks() to use the (newish)\nfind_any_file_locked() so that it doesn\u0027t take a reference on the\nnfs4_file and so never calls nfsd_file_put(), and so never sleeps. With\nthis check is it safe to restore the use of check_for_locks() rather\nthan testing so_count against the mysterious \u00272\u0027.",
"id": "GHSA-x66g-5578-7px9",
"modified": "2026-05-12T12:31:35Z",
"published": "2024-03-13T15:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26629"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/29/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/2"
}
],
"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-X72C-34X9-QRM4
Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-05-24 17:17An issue was discovered in the Linux kernel through 5.6.11. btree_gc_coalesce in drivers/md/bcache/btree.c has a deadlock if a coalescing operation fails.
{
"affected": [],
"aliases": [
"CVE-2020-12771"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-09T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the Linux kernel through 5.6.11. btree_gc_coalesce in drivers/md/bcache/btree.c has a deadlock if a coalescing operation fails.",
"id": "GHSA-x72c-34x9-qrm4",
"modified": "2022-05-24T17:17:34Z",
"published": "2022-05-24T17:17:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12771"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/08/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00034.html"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2020/4/26/87"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200608-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4462-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4463-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4465-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4483-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4485-1"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00071.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00009.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-X72X-2X5Q-H4HW
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-09-26 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Add a lock when accessing the buddy trim function
When running YouTube videos and Steam games simultaneously, the tester found a system hang / race condition issue with the multi-display configuration setting. Adding a lock to the buddy allocator's trim function would be the solution.
[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108 [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250470] Call Trace: [ 7197.250472] [ 7197.250475] ? show_regs+0x6d/0x80 [ 7197.250481] ? die_addr+0x37/0xa0 [ 7197.250483] ? exc_general_protection+0x1db/0x480 [ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper] [ 7197.250493] ? asm_exc_general_protection+0x27/0x30 [ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy] [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy] [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm] [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm] [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm] [ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu] [ 7197.251025] ? try_wait_for_completion+0x59/0x70 [ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0 [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70 [ 7197.251037] drm_atomic_helper_commit+0x84/0x160 [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70 [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850 [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251049] drm_ioctl_kernel+0xb9/0x120 [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251056] drm_ioctl+0x2d4/0x550 [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu] [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0 [ 7197.251190] x64_sys_call+0x143b/0x25c0 [ 7197.251193] do_syscall_64+0x7f/0x180 [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu] [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0 [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5
(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)
{
"affected": [],
"aliases": [
"CVE-2024-57921"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T12:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Add a lock when accessing the buddy trim function\n\nWhen running YouTube videos and Steam games simultaneously,\nthe tester found a system hang / race condition issue with\nthe multi-display configuration setting. Adding a lock to\nthe buddy allocator\u0027s trim function would be the solution.\n\n\u003clog snip\u003e\n[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108\n[ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250470] Call Trace:\n[ 7197.250472] \u003cTASK\u003e\n[ 7197.250475] ? show_regs+0x6d/0x80\n[ 7197.250481] ? die_addr+0x37/0xa0\n[ 7197.250483] ? exc_general_protection+0x1db/0x480\n[ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]\n[ 7197.250493] ? asm_exc_general_protection+0x27/0x30\n[ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy]\n[ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]\n[ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]\n[ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm]\n[ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm]\n[ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm]\n[ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]\n[ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]\n[ 7197.251025] ? try_wait_for_completion+0x59/0x70\n[ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0\n[ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70\n[ 7197.251037] drm_atomic_helper_commit+0x84/0x160\n[ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70\n[ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850\n[ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251049] drm_ioctl_kernel+0xb9/0x120\n[ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251056] drm_ioctl+0x2d4/0x550\n[ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]\n[ 7197.251186] __x64_sys_ioctl+0xa0/0xf0\n[ 7197.251190] x64_sys_call+0x143b/0x25c0\n[ 7197.251193] do_syscall_64+0x7f/0x180\n[ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]\n[ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0\n[ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5\n\n(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)",
"id": "GHSA-x72x-2x5q-h4hw",
"modified": "2025-09-26T21:30:27Z",
"published": "2025-01-19T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57921"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/758e3c3054b65336cf0c5f240221f63b4fb98478"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75c8b703e5bded1e33b08fb09b829e7c2c1ed50a"
}
],
"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-X74C-MR6J-XGX9
Vulnerability from github – Published: 2025-04-17 21:30 – Updated: 2025-04-17 21:30In the Linux kernel, the following vulnerability has been resolved:
block: Fix potential deadlock in blk_ia_range_sysfs_show()
When being read, a sysfs attribute is already protected against removal with the kobject node active reference counter. As a result, in blk_ia_range_sysfs_show(), there is no need to take the queue sysfs lock when reading the value of a range attribute. Using the queue sysfs lock in this function creates a potential deadlock situation with the disk removal, something that a lockdep signals with a splat when the device is removed:
[ 760.703551] Possible unsafe locking scenario: [ 760.703551] [ 760.703554] CPU0 CPU1 [ 760.703556] ---- ---- [ 760.703558] lock(&q->sysfs_lock); [ 760.703565] lock(kn->active#385); [ 760.703573] lock(&q->sysfs_lock); [ 760.703579] lock(kn->active#385); [ 760.703587] [ 760.703587] *** DEADLOCK ***
Solve this by removing the mutex_lock()/mutex_unlock() calls from blk_ia_range_sysfs_show().
{
"affected": [],
"aliases": [
"CVE-2022-49406"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix potential deadlock in blk_ia_range_sysfs_show()\n\nWhen being read, a sysfs attribute is already protected against removal\nwith the kobject node active reference counter. As a result, in\nblk_ia_range_sysfs_show(), there is no need to take the queue sysfs\nlock when reading the value of a range attribute. Using the queue sysfs\nlock in this function creates a potential deadlock situation with the\ndisk removal, something that a lockdep signals with a splat when the\ndevice is removed:\n\n[ 760.703551] Possible unsafe locking scenario:\n[ 760.703551]\n[ 760.703554] CPU0 CPU1\n[ 760.703556] ---- ----\n[ 760.703558] lock(\u0026q-\u003esysfs_lock);\n[ 760.703565] lock(kn-\u003eactive#385);\n[ 760.703573] lock(\u0026q-\u003esysfs_lock);\n[ 760.703579] lock(kn-\u003eactive#385);\n[ 760.703587]\n[ 760.703587] *** DEADLOCK ***\n\nSolve this by removing the mutex_lock()/mutex_unlock() calls from\nblk_ia_range_sysfs_show().",
"id": "GHSA-x74c-mr6j-xgx9",
"modified": "2025-04-17T21:30:44Z",
"published": "2025-04-17T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49406"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41e46b3c2aa24f755b2ae9ec4ce931ba5f0d8532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/717b078bc745ba9a262abebed9806a17e8bbb77b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc107c805cde709866b59867ef72b9390199205e"
}
],
"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-X97P-H9J9-9889
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
{
"affected": [],
"aliases": [
"CVE-2022-49313"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: usb: host: Fix deadlock in oxu_bus_suspend()\n\nThere is a deadlock in oxu_bus_suspend(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | timer_action()\noxu_bus_suspend() | mod_timer()\n spin_lock_irq() //(1) | (wait a time)\n ... | oxu_watchdog()\n del_timer_sync() | spin_lock_irq() //(2)\n (wait timer to stop) | ...\n\nWe hold oxu-\u003elock in position (1) of thread 1, and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need oxu-\u003elock in position (2) of thread 2. As a result,\noxu_bus_suspend() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irq(), which could let timer handler to obtain\nthe needed lock.",
"id": "GHSA-x97p-h9j9-9889",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49313"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df"
}
],
"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-X9P6-4MGW-JM88
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths
There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like:
BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30
Found by Linux Verification Center (linuxtesting.org).
{
"affected": [],
"aliases": [
"CVE-2026-45924"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths\n\nThere are two places where ksmbd_vfs_kern_path_end_removing() needs to be\ncalled in order to balance what the corresponding successful call to\nksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and\nput the taken references. Otherwise there might be potential deadlocks\nand unbalanced locks which are caught like:\n\nBUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596\n last function: handle_ksmbd_work\n2 locks held by kworker/5:21/7596:\n #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660\n #1: ffff888130e966c0 (\u0026type-\u003ei_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660\nCPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\nWorkqueue: ksmbd-io handle_ksmbd_work\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x44/0x5b\n process_one_work.cold+0x57/0x5c\n worker_thread+0x82/0x600\n kthread+0x153/0x190\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e\n\nFound by Linux Verification Center (linuxtesting.org).",
"id": "GHSA-x9p6-4mgw-jm88",
"modified": "2026-06-24T18:32:28Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45924"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c578e8065c4b08d5635a4cbc0f6321df9d20f79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34d6691933682f0516259a31b39d2cebcedec0a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c38600feb81c670edb82e49d201d3d2d00cd4c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e3a3192ef78d8302916408d62813b1fddfc8972"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a09dc10d1353f0e92c21eae2a79af1c2b1ddcde8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf29329a13df79c198b45dfc92577638d30b56fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f221baa80e5959a0c08a7e34abbf2a4d3cf0e1c2"
}
],
"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-X9Q8-72P3-MMVX
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2025-01-13 21:30In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.
{
"affected": [],
"aliases": [
"CVE-2023-52524"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:48Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: llcp: Add lock when modifying device list\n\nThe device list needs its associated lock held when modifying it, or the\nlist could become corrupted, as syzbot discovered.",
"id": "GHSA-x9q8-72p3-mmvx",
"modified": "2025-01-13T21:30:47Z",
"published": "2024-03-03T00:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/191d87a19cf1005ecf41e1ae08d74e17379e8391"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29c16c2bf5866326d5fbc4a537b3997fcac23391"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4837a192f6d06d5bb2f3f47d6ce5353ab69bf86b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7562780e32b84196731d57dd24563546fcf6d082"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dba849cc98113b145c6e720122942c00b8012bdb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dfc7f7a988dad34c3bf4c053124fb26aa6c5f916"
}
],
"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-X9QW-9CW3-55VF
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: avoid deadlock on fence release
Do scheduler queue fence release processing on a workqueue, rather than in the release function itself.
Fixes deadlock issues such as the following:
[ 607.400437] ============================================ [ 607.405755] WARNING: possible recursive locking detected [ 607.415500] -------------------------------------------- [ 607.420817] weston:zfq0/24149 is trying to acquire lock: [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [ 607.436728] but task is already holding lock: [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554 [ 607.451727] other info that might help us debug this: [ 607.458245] Possible unsafe locking scenario:
[ 607.464155] CPU0 [ 607.466601] ---- [ 607.469044] lock(reservation_ww_class_mutex); [ 607.473584] lock(reservation_ww_class_mutex); [ 607.478114] *** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2025-21911"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: avoid deadlock on fence release\n\nDo scheduler queue fence release processing on a workqueue, rather\nthan in the release function itself.\n\nFixes deadlock issues such as the following:\n\n[ 607.400437] ============================================\n[ 607.405755] WARNING: possible recursive locking detected\n[ 607.415500] --------------------------------------------\n[ 607.420817] weston:zfq0/24149 is trying to acquire lock:\n[ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr]\n[ 607.436728]\n but task is already holding lock:\n[ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554\n[ 607.451727]\n other info that might help us debug this:\n[ 607.458245] Possible unsafe locking scenario:\n\n[ 607.464155] CPU0\n[ 607.466601] ----\n[ 607.469044] lock(reservation_ww_class_mutex);\n[ 607.473584] lock(reservation_ww_class_mutex);\n[ 607.478114]\n *** DEADLOCK ***",
"id": "GHSA-x9qw-9cw3-55vf",
"modified": "2025-04-15T18:31:42Z",
"published": "2025-04-01T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21911"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bd8b8d34cf4efba18766d64f817c819ed1bbde7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d993ae7360923efd6ade43a32043459a121c28c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df1a1ed5e1bdd9cc13148e0e5549f5ebcf76cf13"
}
],
"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-XCJG-G59X-3948
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
{
"affected": [],
"aliases": [
"CVE-2024-56533"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.",
"id": "GHSA-xcjg-g59x-3948",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56533"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24fe9f7ca83ec9acf765339054951f5cd9ae5c5d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bd8838c0ea886679a32834fdcacab296d072fbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/befcca1777525e37c659b4129d8ac7463b07ef67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dafb28f02be407e07a6f679e922a626592b481b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e07605d855c4104d981653146a330ea48f6266ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e869642a77a9b3b98b0ab2c8fec7af4385140909"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffbfc6c4330fc233698529656798bee44fea96f5"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/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"
}
]
}
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.