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-833H-M63R-586V
Vulnerability from github – Published: 2022-09-28 00:00 – Updated: 2025-05-21 18:33A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition
{
"affected": [],
"aliases": [
"CVE-2022-3303"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-27T23:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition",
"id": "GHSA-833h-m63r-586v",
"modified": "2025-05-21T18:33:04Z",
"published": "2022-09-28T00:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5257"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-85Q7-HHCQ-PR4H
Vulnerability from github – Published: 2025-03-11 00:31 – Updated: 2025-03-11 00:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between concurrent dio writes when low on free data space
When reserving data space for a direct IO write we can end up deadlocking if we have multiple tasks attempting a write to the same file range, there are multiple extents covered by that file range, we are low on available space for data and the writes don't expand the inode's i_size.
The deadlock can happen like this:
1) We have a file with an i_size of 1M, at offset 0 it has an extent with a size of 128K and at offset 128K it has another extent also with a size of 128K;
2) Task A does a direct IO write against file range [0, 256K), and because the write is within the i_size boundary, it takes the inode's lock (VFS level) in shared mode;
3) Task A locks the file range [0, 256K) at btrfs_dio_iomap_begin(), and then gets the extent map for the extent covering the range [0, 128K). At btrfs_get_blocks_direct_write(), it creates an ordered extent for that file range ([0, 128K));
4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file range [0, 256K);
5) Task A executes btrfs_dio_iomap_begin() again, this time for the file range [128K, 256K), and locks the file range [128K, 256K);
6) Task B starts a direct IO write against file range [0, 256K) as well. It also locks the inode in shared mode, as it's within the i_size limit, and then tries to lock file range [0, 256K). It is able to lock the subrange [0, 128K) but then blocks waiting for the range [128K, 256K), as it is currently locked by task A;
7) Task A enters btrfs_get_blocks_direct_write() and tries to reserve data space. Because we are low on available free space, it triggers the async data reclaim task, and waits for it to reserve data space;
8) The async reclaim task decides to wait for all existing ordered extents to complete (through btrfs_wait_ordered_roots()). It finds the ordered extent previously created by task A for the file range [0, 128K) and waits for it to complete;
9) The ordered extent for the file range [0, 128K) can not complete because it blocks at btrfs_finish_ordered_io() when trying to lock the file range [0, 128K).
This results in a deadlock, because:
-
task B is holding the file range [0, 128K) locked, waiting for the range [128K, 256K) to be unlocked by task A;
-
task A is holding the file range [128K, 256K) locked and it's waiting for the async data reclaim task to satisfy its space reservation request;
-
the async data reclaim task is waiting for ordered extent [0, 128K) to complete, but the ordered extent can not complete because the file range [0, 128K) is currently locked by task B, which is waiting on task A to unlock file range [128K, 256K) and task A waiting on the async data reclaim task.
This results in a deadlock between 4 task: task A, task B, the async data reclaim task and the task doing ordered extent completion (a work queue task).
This type of deadlock can sporadically be triggered by the test case generic/300 from fstests, and results in a stack trace like the following:
[12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds. [12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000 [12084.036554] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] Call Trace: [12084.036601] [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0 [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs] [12084.0367 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49547"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between concurrent dio writes when low on free data space\n\nWhen reserving data space for a direct IO write we can end up deadlocking\nif we have multiple tasks attempting a write to the same file range, there\nare multiple extents covered by that file range, we are low on available\nspace for data and the writes don\u0027t expand the inode\u0027s i_size.\n\nThe deadlock can happen like this:\n\n1) We have a file with an i_size of 1M, at offset 0 it has an extent with\n a size of 128K and at offset 128K it has another extent also with a\n size of 128K;\n\n2) Task A does a direct IO write against file range [0, 256K), and because\n the write is within the i_size boundary, it takes the inode\u0027s lock (VFS\n level) in shared mode;\n\n3) Task A locks the file range [0, 256K) at btrfs_dio_iomap_begin(), and\n then gets the extent map for the extent covering the range [0, 128K).\n At btrfs_get_blocks_direct_write(), it creates an ordered extent for\n that file range ([0, 128K));\n\n4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file\n range [0, 256K);\n\n5) Task A executes btrfs_dio_iomap_begin() again, this time for the file\n range [128K, 256K), and locks the file range [128K, 256K);\n\n6) Task B starts a direct IO write against file range [0, 256K) as well.\n It also locks the inode in shared mode, as it\u0027s within the i_size limit,\n and then tries to lock file range [0, 256K). It is able to lock the\n subrange [0, 128K) but then blocks waiting for the range [128K, 256K),\n as it is currently locked by task A;\n\n7) Task A enters btrfs_get_blocks_direct_write() and tries to reserve data\n space. Because we are low on available free space, it triggers the\n async data reclaim task, and waits for it to reserve data space;\n\n8) The async reclaim task decides to wait for all existing ordered extents\n to complete (through btrfs_wait_ordered_roots()).\n It finds the ordered extent previously created by task A for the file\n range [0, 128K) and waits for it to complete;\n\n9) The ordered extent for the file range [0, 128K) can not complete\n because it blocks at btrfs_finish_ordered_io() when trying to lock the\n file range [0, 128K).\n\n This results in a deadlock, because:\n\n - task B is holding the file range [0, 128K) locked, waiting for the\n range [128K, 256K) to be unlocked by task A;\n\n - task A is holding the file range [128K, 256K) locked and it\u0027s waiting\n for the async data reclaim task to satisfy its space reservation\n request;\n\n - the async data reclaim task is waiting for ordered extent [0, 128K)\n to complete, but the ordered extent can not complete because the\n file range [0, 128K) is currently locked by task B, which is waiting\n on task A to unlock file range [128K, 256K) and task A waiting\n on the async data reclaim task.\n\n This results in a deadlock between 4 task: task A, task B, the async\n data reclaim task and the task doing ordered extent completion (a work\n queue task).\n\nThis type of deadlock can sporadically be triggered by the test case\ngeneric/300 from fstests, and results in a stack trace like the following:\n\n[12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds.\n[12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1\n[12084.035562] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000\n[12084.036554] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n[12084.036599] Call Trace:\n[12084.036601] \u003cTASK\u003e\n[12084.036606] __schedule+0x3cb/0xed0\n[12084.036616] schedule+0x4e/0xb0\n[12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs]\n[12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0\n[12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs]\n[12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs]\n[12084.0367\n---truncated---",
"id": "GHSA-85q7-hhcq-pr4h",
"modified": "2025-03-11T00:31:48Z",
"published": "2025-03-11T00:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49547"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfae6f765b3c40882ee90dae8fbf9325c8de9c35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5585f4f0ef5b17026bbd60fbff6fcc91b99d5bf"
}
],
"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-85XW-CV8G-9227
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2025-11-03 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when cloning inline extents and using qgroups
There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode.
When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space").
However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction.
When this issue happens, stack traces like the following are reported:
[72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30
[72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30
[72747.569686] task:fsstress state:D stack:
---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-46987"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when cloning inline extents and using qgroups\n\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\n\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination\u0027s inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\n\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode\u0027s iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\n\nWhen this issue happens, stack traces like the following are reported:\n\n [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000\n [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n [72747.556271] Call Trace:\n [72747.556273] __schedule+0x296/0x760\n [72747.556277] schedule+0x3c/0xa0\n [72747.556279] io_schedule+0x12/0x40\n [72747.556284] __lock_page+0x13c/0x280\n [72747.556287] ? generic_file_readonly_mmap+0x70/0x70\n [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]\n [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160\n [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n [72747.556362] ? update_group_capacity+0x25/0x210\n [72747.556366] ? cpumask_next_and+0x1a/0x20\n [72747.556391] extent_writepages+0x44/0xa0 [btrfs]\n [72747.556394] do_writepages+0x41/0xd0\n [72747.556398] __writeback_single_inode+0x39/0x2a0\n [72747.556403] writeback_sb_inodes+0x1ea/0x440\n [72747.556407] __writeback_inodes_wb+0x5f/0xc0\n [72747.556410] wb_writeback+0x235/0x2b0\n [72747.556414] ? get_nr_inodes+0x35/0x50\n [72747.556417] wb_workfn+0x354/0x490\n [72747.556420] ? newidle_balance+0x2c5/0x3e0\n [72747.556424] process_one_work+0x1aa/0x340\n [72747.556426] worker_thread+0x30/0x390\n [72747.556429] ? create_worker+0x1a0/0x1a0\n [72747.556432] kthread+0x116/0x130\n [72747.556435] ? kthread_park+0x80/0x80\n [72747.556438] ret_from_fork+0x1f/0x30\n\n [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n [72747.566961] Call Trace:\n [72747.566964] __schedule+0x296/0x760\n [72747.566968] ? finish_wait+0x80/0x80\n [72747.566970] schedule+0x3c/0xa0\n [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n [72747.566999] ? finish_wait+0x80/0x80\n [72747.567024] lock_extent_bits+0x37/0x90 [btrfs]\n [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380\n [72747.567076] __extent_writepage+0x203/0x320 [btrfs]\n [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]\n [72747.567106] ? update_load_avg+0x7e/0x5f0\n [72747.567109] ? enqueue_entity+0xf4/0x6f0\n [72747.567134] extent_writepages+0x44/0xa0 [btrfs]\n [72747.567137] ? enqueue_task_fair+0x93/0x6f0\n [72747.567140] do_writepages+0x41/0xd0\n [72747.567144] __filemap_fdatawrite_range+0xc7/0x100\n [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]\n [72747.567200] process_one_work+0x1aa/0x340\n [72747.567202] worker_thread+0x30/0x390\n [72747.567205] ? create_worker+0x1a0/0x1a0\n [72747.567208] kthread+0x116/0x130\n [72747.567211] ? kthread_park+0x80/0x80\n [72747.567214] ret_from_fork+0x1f/0x30\n\n [72747.569686] task:fsstress state:D stack: \n---truncated---",
"id": "GHSA-85xw-cv8g-9227",
"modified": "2025-11-03T18:31:13Z",
"published": "2024-02-28T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8fbbd06fab9b75dcd68d850fe318ac3bc128974"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-866W-999J-PR8G
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 15:33In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Add missing save/restore handling of LBR MSRs
MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken.
Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state().
Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore.
Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop).
[sean: guard with lbrv checks, massage changelog]
{
"affected": [],
"aliases": [
"CVE-2026-46014"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled. Additionally, to correctly restore L1\u0027s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0027t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\"KVM:\nIgnore DEBUGCTL MSRs with no effect\") (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog]",
"id": "GHSA-866w-999j-pr8g",
"modified": "2026-06-16T15:33:41Z",
"published": "2026-05-27T15:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13a89ada5dcfc2539514c83ba5a2c61157f1ec6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b922a42b531a82d7881add14a7698dcdc5e1f0a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3700f0788da6acf73b2df56690f4b201aa4aefd2"
}
],
"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-86M3-4Q38-6PRJ
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-07-17 18:31In the Linux kernel, the following vulnerability has been resolved:
aoe: avoid potential deadlock at set_capacity
Move set_capacity() outside of the section procected by (&d->lock). To avoid possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
[1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock);
*** DEADLOCK ***
Where 1 hold by zram_add()->set_capacity(). [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc() is trying to acquire 3 at set_capacity() call. In this situation an attempt to acquire [4]lock(&d->lock) from aoecmd_cfg_rsp() will lead to deadlock.
So the simplest solution is breaking lock dependency 2 -> 3 by moving set_capacity() outside.
{
"affected": [],
"aliases": [
"CVE-2024-26775"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naoe: avoid potential deadlock at set_capacity\n\nMove set_capacity() outside of the section procected by (\u0026d-\u003elock).\nTo avoid possible interrupt unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n[1] lock(\u0026bdev-\u003ebd_size_lock);\n local_irq_disable();\n [2] lock(\u0026d-\u003elock);\n [3] lock(\u0026bdev-\u003ebd_size_lock);\n \u003cInterrupt\u003e\n[4] lock(\u0026d-\u003elock);\n\n *** DEADLOCK ***\n\nWhere [1](\u0026bdev-\u003ebd_size_lock) hold by zram_add()-\u003eset_capacity().\n[2]lock(\u0026d-\u003elock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()\nis trying to acquire [3](\u0026bdev-\u003ebd_size_lock) at set_capacity() call.\nIn this situation an attempt to acquire [4]lock(\u0026d-\u003elock) from\naoecmd_cfg_rsp() will lead to deadlock.\n\nSo the simplest solution is breaking lock dependency\n[2](\u0026d-\u003elock) -\u003e [3](\u0026bdev-\u003ebd_size_lock) by moving set_capacity()\noutside.",
"id": "GHSA-86m3-4q38-6prj",
"modified": "2025-07-17T18:31:03Z",
"published": "2024-04-03T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2499fa286fb010ceb289950050199f33c26667b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86"
}
],
"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-872R-39GX-CVPQ
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-09-23 18:30In the Linux kernel, the following vulnerability has been resolved:
stackdepot: fix stack_depot_save_flags() in NMI context
Per documentation, stack_depot_save_flags() was meant to be usable from NMI context if STACK_DEPOT_FLAG_CAN_ALLOC is unset. However, it still would try to take the pool_lock in an attempt to save a stack trace in the current pool (if space is available).
This could result in deadlock if an NMI is handled while pool_lock is already held. To avoid deadlock, only try to take the lock in NMI context and give up if unsuccessful.
The documentation is fixed to clearly convey this.
{
"affected": [],
"aliases": [
"CVE-2024-48876"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstackdepot: fix stack_depot_save_flags() in NMI context\n\nPer documentation, stack_depot_save_flags() was meant to be usable from\nNMI context if STACK_DEPOT_FLAG_CAN_ALLOC is unset. However, it still\nwould try to take the pool_lock in an attempt to save a stack trace in the\ncurrent pool (if space is available).\n\nThis could result in deadlock if an NMI is handled while pool_lock is\nalready held. To avoid deadlock, only try to take the lock in NMI context\nand give up if unsuccessful.\n\nThe documentation is fixed to clearly convey this.",
"id": "GHSA-872r-39gx-cvpq",
"modified": "2025-09-23T18:30:20Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48876"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/031e04bdc834cda3b054ef6b698503b2b97e8186"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bfeeeff2c92b9dd261198b601b45bde4c529841"
}
],
"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-876R-CHC7-85M3
Vulnerability from github – Published: 2022-05-01 07:17 – Updated: 2024-02-15 21:31The kernel in Red Hat Enterprise Linux 3, when running on SMP systems, allows local users to cause a denial of service (deadlock) by running the shmat function on an shm at the same time that shmctl is removing that shm (IPC_RMID), which prevents a spinlock from being unlocked.
{
"affected": [],
"aliases": [
"CVE-2006-4342"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-10-17T17:07:00Z",
"severity": "MODERATE"
},
"details": "The kernel in Red Hat Enterprise Linux 3, when running on SMP systems, allows local users to cause a denial of service (deadlock) by running the shmat function on an shm at the same time that shmctl is removing that shm (IPC_RMID), which prevents a spinlock from being unlocked.",
"id": "GHSA-876r-chc7-85m3",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T07:17:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-4342"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205618"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A9649"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22497"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/23064"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2006-254.htm"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/245984"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2006-0710.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-88RQ-Q8GM-2CHX
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
f2fs: initialize locks earlier in f2fs_fill_super()
syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation.
{
"affected": [],
"aliases": [
"CVE-2022-49742"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: initialize locks earlier in f2fs_fill_super()\n\nsyzbot is reporting lockdep warning at f2fs_handle_error() [1], for\nspin_lock(\u0026sbi-\u003eerror_lock) is called before spin_lock_init() is called.\nFor safe locking in error handling, move initialization of locks (and\nobvious structures) in f2fs_fill_super() to immediately after memory\nallocation.",
"id": "GHSA-88rq-q8gm-2chx",
"modified": "2025-04-14T21:32:23Z",
"published": "2025-03-27T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49742"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92b4cf5b48955a4bdd15fe4e2067db8ebd87f04c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ddeff03bb33810fcf2f0c18e03d099cf0aacda62"
}
],
"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-8C6W-27GC-G7XG
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2024-04-29 21:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve
At btrfs_use_block_rsv() we read the size of a block reserve without locking its spinlock, which makes KCSAN complain because the size of a block reserve is always updated while holding its spinlock. The report from KCSAN is the following:
[653.313148] BUG: KCSAN: data-race in btrfs_update_delayed_refs_rsv [btrfs] / btrfs_use_block_rsv [btrfs]
[653.314755] read to 0x000000017f5871b8 of 8 bytes by task 7519 on cpu 0: [653.314779] btrfs_use_block_rsv+0xe4/0x2f8 [btrfs] [653.315606] btrfs_alloc_tree_block+0xdc/0x998 [btrfs] [653.316421] btrfs_force_cow_block+0x220/0xe38 [btrfs] [653.317242] btrfs_cow_block+0x1ac/0x568 [btrfs] [653.318060] btrfs_search_slot+0xda2/0x19b8 [btrfs] [653.318879] btrfs_del_csums+0x1dc/0x798 [btrfs] [653.319702] __btrfs_free_extent.isra.0+0xc24/0x2028 [btrfs] [653.320538] __btrfs_run_delayed_refs+0xd3c/0x2390 [btrfs] [653.321340] btrfs_run_delayed_refs+0xae/0x290 [btrfs] [653.322140] flush_space+0x5e4/0x718 [btrfs] [653.322958] btrfs_preempt_reclaim_metadata_space+0x102/0x2f8 [btrfs] [653.323781] process_one_work+0x3b6/0x838 [653.323800] worker_thread+0x75e/0xb10 [653.323817] kthread+0x21a/0x230 [653.323836] __ret_from_fork+0x6c/0xb8 [653.323855] ret_from_fork+0xa/0x30
[653.323887] write to 0x000000017f5871b8 of 8 bytes by task 576 on cpu 3: [653.323906] btrfs_update_delayed_refs_rsv+0x1a4/0x250 [btrfs] [653.324699] btrfs_add_delayed_data_ref+0x468/0x6d8 [btrfs] [653.325494] btrfs_free_extent+0x76/0x120 [btrfs] [653.326280] __btrfs_mod_ref+0x6a8/0x6b8 [btrfs] [653.327064] btrfs_dec_ref+0x50/0x70 [btrfs] [653.327849] walk_up_proc+0x236/0xa50 [btrfs] [653.328633] walk_up_tree+0x21c/0x448 [btrfs] [653.329418] btrfs_drop_snapshot+0x802/0x1328 [btrfs] [653.330205] btrfs_clean_one_deleted_snapshot+0x184/0x238 [btrfs] [653.330995] cleaner_kthread+0x2b0/0x2f0 [btrfs] [653.331781] kthread+0x21a/0x230 [653.331800] __ret_from_fork+0x6c/0xb8 [653.331818] ret_from_fork+0xa/0x30
So add a helper to get the size of a block reserve while holding the lock. Reading the field while holding the lock instead of using the data_race() annotation is used in order to prevent load tearing.
{
"affected": [],
"aliases": [
"CVE-2024-26904"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve\n\nAt btrfs_use_block_rsv() we read the size of a block reserve without\nlocking its spinlock, which makes KCSAN complain because the size of a\nblock reserve is always updated while holding its spinlock. The report\nfrom KCSAN is the following:\n\n [653.313148] BUG: KCSAN: data-race in btrfs_update_delayed_refs_rsv [btrfs] / btrfs_use_block_rsv [btrfs]\n\n [653.314755] read to 0x000000017f5871b8 of 8 bytes by task 7519 on cpu 0:\n [653.314779] btrfs_use_block_rsv+0xe4/0x2f8 [btrfs]\n [653.315606] btrfs_alloc_tree_block+0xdc/0x998 [btrfs]\n [653.316421] btrfs_force_cow_block+0x220/0xe38 [btrfs]\n [653.317242] btrfs_cow_block+0x1ac/0x568 [btrfs]\n [653.318060] btrfs_search_slot+0xda2/0x19b8 [btrfs]\n [653.318879] btrfs_del_csums+0x1dc/0x798 [btrfs]\n [653.319702] __btrfs_free_extent.isra.0+0xc24/0x2028 [btrfs]\n [653.320538] __btrfs_run_delayed_refs+0xd3c/0x2390 [btrfs]\n [653.321340] btrfs_run_delayed_refs+0xae/0x290 [btrfs]\n [653.322140] flush_space+0x5e4/0x718 [btrfs]\n [653.322958] btrfs_preempt_reclaim_metadata_space+0x102/0x2f8 [btrfs]\n [653.323781] process_one_work+0x3b6/0x838\n [653.323800] worker_thread+0x75e/0xb10\n [653.323817] kthread+0x21a/0x230\n [653.323836] __ret_from_fork+0x6c/0xb8\n [653.323855] ret_from_fork+0xa/0x30\n\n [653.323887] write to 0x000000017f5871b8 of 8 bytes by task 576 on cpu 3:\n [653.323906] btrfs_update_delayed_refs_rsv+0x1a4/0x250 [btrfs]\n [653.324699] btrfs_add_delayed_data_ref+0x468/0x6d8 [btrfs]\n [653.325494] btrfs_free_extent+0x76/0x120 [btrfs]\n [653.326280] __btrfs_mod_ref+0x6a8/0x6b8 [btrfs]\n [653.327064] btrfs_dec_ref+0x50/0x70 [btrfs]\n [653.327849] walk_up_proc+0x236/0xa50 [btrfs]\n [653.328633] walk_up_tree+0x21c/0x448 [btrfs]\n [653.329418] btrfs_drop_snapshot+0x802/0x1328 [btrfs]\n [653.330205] btrfs_clean_one_deleted_snapshot+0x184/0x238 [btrfs]\n [653.330995] cleaner_kthread+0x2b0/0x2f0 [btrfs]\n [653.331781] kthread+0x21a/0x230\n [653.331800] __ret_from_fork+0x6c/0xb8\n [653.331818] ret_from_fork+0xa/0x30\n\nSo add a helper to get the size of a block reserve while holding the lock.\nReading the field while holding the lock instead of using the data_race()\nannotation is used in order to prevent load tearing.",
"id": "GHSA-8c6w-27gc-g7xg",
"modified": "2024-04-29T21:30:33Z",
"published": "2024-04-17T12:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26904"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2daa2a8e895e6dc2395f8628c011bcf1e019040d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9422d35d574b646269ca46010a835ca074b310"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab1be3f1aa7799f99155488c28eacaef65eb68fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7bb26b847e5b97814f522686068c5628e2b3646"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6d4d29a12655b42a13cec038c2902bb7efc50ed"
}
],
"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-8CWG-3MF2-HG4C
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30In setUpdatableDriverPath of GpuService.cpp, there is a possible memory corruption due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-162383705
{
"affected": [],
"aliases": [
"CVE-2020-0420"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-14T14:15:00Z",
"severity": "HIGH"
},
"details": "In setUpdatableDriverPath of GpuService.cpp, there is a possible memory corruption due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-162383705",
"id": "GHSA-8cwg-3mf2-hg4c",
"modified": "2022-05-24T17:30:38Z",
"published": "2022-05-24T17:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0420"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-10-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.