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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-HFRJ-R4V7-3997
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-02 21:32In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison
Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap:
thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK!
The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock.
Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock.
[akpm@linux-foundation.org: fix race, rename label per Miaohe]
{
"affected": [],
"aliases": [
"CVE-2026-53207"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison\n\nTwo concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can\ntrigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock\nwhen racing with a concurrent unmap:\n\n thread#0 thread#1\n -------- --------\n madvise(folio, MADV_HWPOISON)\n -\u003e poisons the folio successfully\n madvise(folio, MADV_HWPOISON) unmap(folio)\n try_memory_failure_hugetlb\n get_huge_page_for_hwpoison\n spin_lock_irq(\u0026hugetlb_lock) \u003c- held\n __get_huge_page_for_hwpoison\n hugetlb_update_hwpoison()\n -\u003e MF_HUGETLB_FOLIO_PRE_POISONED\n goto out:\n folio_put()\n refcount: 1 -\u003e 0\n free_huge_folio()\n spin_lock_irqsave(\u0026hugetlb_lock)\n -\u003e AA DEADLOCK!\n\nThe out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop\nthe GUP reference while the hugetlb_lock is still held by the hugetlb.c\nwrapper get_huge_page_for_hwpoison(). If concurrent unmap has released\nthe page table mapping reference, folio_put() drops the folio refcount to\nzero, triggering free_huge_folio() which attempts to re-acquire the\nnon-recursive hugetlb_lock.\n\nFix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper\ninto get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the\nfolio_put() at the out: label so the folio is always released outside the\nlock.\n\n[akpm@linux-foundation.org: fix race, rename label per Miaohe]",
"id": "GHSA-hfrj-r4v7-3997",
"modified": "2026-07-02T21:32:04Z",
"published": "2026-06-25T09:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c2d42b8ee345b17a4ba56b0f6492d1ff4c1178e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77b73b54801ae7137479c141fd0473a491c1dc48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a33bfed648c10f5a1519981dbfad80841191edc8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf7ba8f96c258c30393814491930ae4ecdc5fe5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd77a83915b07e2b0205adb284f08b39ae31dc4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc3ff42cb0cbf947e4600ae9761c3783760050e2"
}
],
"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-HG9C-4Q92-WHW7
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock with fiemap and extent locking
While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.
This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it.
Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace
[<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.
To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before.
The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag.
With this patch applied we no longer deadlock with my testcase.
{
"affected": [],
"aliases": [
"CVE-2024-35784"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T13:15:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock with fiemap and extent locking\n\nWhile working on the patchset to remove extent locking I got a lockdep\nsplat with fiemap and pagefaulting with my new extent lock replacement\nlock.\n\nThis deadlock exists with our normal code, we just don\u0027t have lockdep\nannotations with the extent locking so we\u0027ve never noticed it.\n\nSince we\u0027re copying the fiemap extent to user space on every iteration\nwe have the chance of pagefaulting. Because we hold the extent lock for\nthe entire range we could mkwrite into a range in the file that we have\nmmap\u0027ed. This would deadlock with the following stack trace\n\n[\u003c0\u003e] lock_extent+0x28d/0x2f0\n[\u003c0\u003e] btrfs_page_mkwrite+0x273/0x8a0\n[\u003c0\u003e] do_page_mkwrite+0x50/0xb0\n[\u003c0\u003e] do_fault+0xc1/0x7b0\n[\u003c0\u003e] __handle_mm_fault+0x2fa/0x460\n[\u003c0\u003e] handle_mm_fault+0xa4/0x330\n[\u003c0\u003e] do_user_addr_fault+0x1f4/0x800\n[\u003c0\u003e] exc_page_fault+0x7c/0x1e0\n[\u003c0\u003e] asm_exc_page_fault+0x26/0x30\n[\u003c0\u003e] rep_movs_alternative+0x33/0x70\n[\u003c0\u003e] _copy_to_user+0x49/0x70\n[\u003c0\u003e] fiemap_fill_next_extent+0xc8/0x120\n[\u003c0\u003e] emit_fiemap_extent+0x4d/0xa0\n[\u003c0\u003e] extent_fiemap+0x7f8/0xad0\n[\u003c0\u003e] btrfs_fiemap+0x49/0x80\n[\u003c0\u003e] __x64_sys_ioctl+0x3e1/0xb50\n[\u003c0\u003e] do_syscall_64+0x94/0x1a0\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nI wrote an fstest to reproduce this deadlock without my replacement lock\nand verified that the deadlock exists with our existing locking.\n\nTo fix this simply don\u0027t take the extent lock for the entire duration of\nthe fiemap. This is safe in general because we keep track of where we\nare when we\u0027re searching the tree, so if an ordered extent updates in\nthe middle of our fiemap call we\u0027ll still emit the correct extents\nbecause we know what offset we were on before.\n\nThe only place we maintain the lock is searching delalloc. Since the\ndelalloc stuff can change during writeback we want to lock the extent\nrange so we have a consistent view of delalloc at the time we\u0027re\nchecking to see if we need to set the delalloc flag.\n\nWith this patch applied we no longer deadlock with my testcase.",
"id": "GHSA-hg9c-4q92-whw7",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35784"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"
}
],
"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-HG9V-MFMX-JX2X
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-02-03 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't take dev_replace rwsem on task already holding it
Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of the RAID stripe-tree, we get the following splat from lockdep:
BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started
============================================ WARNING: possible recursive locking detected 6.11.0-rc3-btrfs-for-next #599 Not tainted
btrfs/2326 is trying to acquire lock: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
but task is already holding lock: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&fs_info->dev_replace.rwsem); lock(&fs_info->dev_replace.rwsem);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by btrfs/2326: #0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
stack backtrace: CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x5b/0x80 __lock_acquire+0x2798/0x69d0 ? __pfxlockacquire+0x10/0x10 ? pfxlockacquire+0x10/0x10 lock_acquire+0x19d/0x4a0 ? btrfs_map_block+0x39f/0x2250 ? pfx_lock_acquire+0x10/0x10 ? find_held_lock+0x2d/0x110 ? lock_is_held_type+0x8f/0x100 down_read+0x8e/0x440 ? btrfs_map_block+0x39f/0x2250 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 btrfs_map_block+0x39f/0x2250 ? btrfs_dev_replace_by_ioctl+0xd69/0x1d00 ? btrfs_bio_counter_inc_blocked+0xd9/0x2e0 ? __kasan_slab_alloc+0x6e/0x70 ? __pfx_btrfs_map_block+0x10/0x10 ? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10 ? kmem_cache_alloc_noprof+0x1f2/0x300 ? mempool_alloc_noprof+0xed/0x2b0 btrfs_submit_chunk+0x28d/0x17e0 ? __pfx_btrfs_submit_chunk+0x10/0x10 ? bvec_alloc+0xd7/0x1b0 ? bio_add_folio+0x171/0x270 ? __pfx_bio_add_folio+0x10/0x10 ? __kasan_check_read+0x20/0x20 btrfs_submit_bio+0x37/0x80 read_extent_buffer_pages+0x3df/0x6c0 btrfs_read_extent_buffer+0x13e/0x5f0 read_tree_block+0x81/0xe0 read_block_for_search+0x4bd/0x7a0 ? __pfx_read_block_for_search+0x10/0x10 btrfs_search_slot+0x78d/0x2720 ? __pfx_btrfs_search_slot+0x10/0x10 ? lock_is_held_type+0x8f/0x100 ? kasan_save_track+0x14/0x30 ? __kasan_slab_alloc+0x6e/0x70 ? kmem_cache_alloc_noprof+0x1f2/0x300 btrfs_get_raid_extent_offset+0x181/0x820 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_btrfs_get_raid_extent_offset+0x10/0x10 ? down_read+0x194/0x440 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 btrfs_map_block+0x5b5/0x2250 ? __pfx_btrfs_map_block+0x10/0x10 scrub_submit_initial_read+0x8fe/0x11b0 ? __pfx_scrub_submit_initial_read+0x10/0x10 submit_initial_group_read+0x161/0x3a0 ? lock_release+0x20e/0x710 ? __pfx_submit_initial_group_read+0x10/0x10 ? __pfx_lock_release+0x10/0x10 scrub_simple_mirror.isra.0+0x3eb/0x580 scrub_stripe+0xe4d/0x1440 ? lock_release+0x20e/0x710 ? __pfx_scrub_stripe+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 scrub_chunk+0x257/0x4a0 scrub_enumerate_chunks+0x64c/0xf70 ? __mutex_unlock_slowpath+0x147/0x5f0 ? __pfx_scrub_enumerate_chunks+0x10/0x10 ? bit_wait_timeout+0xb0/0x170 ? __up_read+0x189/0x700 ? scrub_workers_get+0x231/0x300 ? up_write+0x490/0x4f0 btrfs_scrub_dev+0x52e/0xcd0 ? create_pending_snapshots+0x230/0x250 ? __pfx_btrfs_scrub_dev+0x10/0x10 btrfs_dev_replace_by_ioctl+0xd69/0x1d00 ? lock_acquire+0x19d/0x4a0 ? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10 ? ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-48875"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don\u0027t take dev_replace rwsem on task already holding it\n\nRunning fstests btrfs/011 with MKFS_OPTIONS=\"-O rst\" to force the usage of\nthe RAID stripe-tree, we get the following splat from lockdep:\n\n BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started\n\n ============================================\n WARNING: possible recursive locking detected\n 6.11.0-rc3-btrfs-for-next #599 Not tainted\n --------------------------------------------\n btrfs/2326 is trying to acquire lock:\n ffff88810f215c98 (\u0026fs_info-\u003edev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n but task is already holding lock:\n ffff88810f215c98 (\u0026fs_info-\u003edev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026fs_info-\u003edev_replace.rwsem);\n lock(\u0026fs_info-\u003edev_replace.rwsem);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n 1 lock held by btrfs/2326:\n #0: ffff88810f215c98 (\u0026fs_info-\u003edev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n stack backtrace:\n CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599\n Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x5b/0x80\n __lock_acquire+0x2798/0x69d0\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n lock_acquire+0x19d/0x4a0\n ? btrfs_map_block+0x39f/0x2250\n ? __pfx_lock_acquire+0x10/0x10\n ? find_held_lock+0x2d/0x110\n ? lock_is_held_type+0x8f/0x100\n down_read+0x8e/0x440\n ? btrfs_map_block+0x39f/0x2250\n ? __pfx_down_read+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n btrfs_map_block+0x39f/0x2250\n ? btrfs_dev_replace_by_ioctl+0xd69/0x1d00\n ? btrfs_bio_counter_inc_blocked+0xd9/0x2e0\n ? __kasan_slab_alloc+0x6e/0x70\n ? __pfx_btrfs_map_block+0x10/0x10\n ? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10\n ? kmem_cache_alloc_noprof+0x1f2/0x300\n ? mempool_alloc_noprof+0xed/0x2b0\n btrfs_submit_chunk+0x28d/0x17e0\n ? __pfx_btrfs_submit_chunk+0x10/0x10\n ? bvec_alloc+0xd7/0x1b0\n ? bio_add_folio+0x171/0x270\n ? __pfx_bio_add_folio+0x10/0x10\n ? __kasan_check_read+0x20/0x20\n btrfs_submit_bio+0x37/0x80\n read_extent_buffer_pages+0x3df/0x6c0\n btrfs_read_extent_buffer+0x13e/0x5f0\n read_tree_block+0x81/0xe0\n read_block_for_search+0x4bd/0x7a0\n ? __pfx_read_block_for_search+0x10/0x10\n btrfs_search_slot+0x78d/0x2720\n ? __pfx_btrfs_search_slot+0x10/0x10\n ? lock_is_held_type+0x8f/0x100\n ? kasan_save_track+0x14/0x30\n ? __kasan_slab_alloc+0x6e/0x70\n ? kmem_cache_alloc_noprof+0x1f2/0x300\n btrfs_get_raid_extent_offset+0x181/0x820\n ? __pfx_lock_acquire+0x10/0x10\n ? __pfx_btrfs_get_raid_extent_offset+0x10/0x10\n ? down_read+0x194/0x440\n ? __pfx_down_read+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n btrfs_map_block+0x5b5/0x2250\n ? __pfx_btrfs_map_block+0x10/0x10\n scrub_submit_initial_read+0x8fe/0x11b0\n ? __pfx_scrub_submit_initial_read+0x10/0x10\n submit_initial_group_read+0x161/0x3a0\n ? lock_release+0x20e/0x710\n ? __pfx_submit_initial_group_read+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n scrub_simple_mirror.isra.0+0x3eb/0x580\n scrub_stripe+0xe4d/0x1440\n ? lock_release+0x20e/0x710\n ? __pfx_scrub_stripe+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n scrub_chunk+0x257/0x4a0\n scrub_enumerate_chunks+0x64c/0xf70\n ? __mutex_unlock_slowpath+0x147/0x5f0\n ? __pfx_scrub_enumerate_chunks+0x10/0x10\n ? bit_wait_timeout+0xb0/0x170\n ? __up_read+0x189/0x700\n ? scrub_workers_get+0x231/0x300\n ? up_write+0x490/0x4f0\n btrfs_scrub_dev+0x52e/0xcd0\n ? create_pending_snapshots+0x230/0x250\n ? __pfx_btrfs_scrub_dev+0x10/0x10\n btrfs_dev_replace_by_ioctl+0xd69/0x1d00\n ? lock_acquire+0x19d/0x4a0\n ? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10\n ?\n---truncated---",
"id": "GHSA-hg9v-mfmx-jx2x",
"modified": "2025-02-03T15:32:01Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48875"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cca35cb29f81eba3e96ec44dad8696c8a2f9138"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2e99dcd7aafa9d474f7d9b0740b8f93c4e156c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5bc4e030f50fdbb1fbc69acc1e0c5f57c79d044"
}
],
"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-HGM3-GQ5F-VJWG
Vulnerability from github – Published: 2025-01-21 15:31 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: don't keep queue frozen during system suspend
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().
[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.
{
"affected": [],
"aliases": [
"CVE-2024-57946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T13:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-blk: don\u0027t keep queue frozen during system suspend\n\nCommit 4ce6e2db00de (\"virtio-blk: Ensure no requests in virtqueues before\ndeleting vqs.\") replaces queue quiesce with queue freeze in virtio-blk\u0027s\nPM callbacks. And the motivation is to drain inflight IOs before suspending.\n\nblock layer\u0027s queue freeze looks very handy, but it is also easy to cause\ndeadlock, such as, any attempt to call into bio_queue_enter() may run into\ndeadlock if the queue is frozen in current context. There are all kinds\nof -\u003esuspend() called in suspend context, so keeping queue frozen in the\nwhole suspend context isn\u0027t one good idea. And Marek reported lockdep\nwarning[1] caused by virtio-blk\u0027s freeze queue in virtblk_freeze().\n\n[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/\n\nGiven the motivation is to drain in-flight IOs, it can be done by calling\nfreeze \u0026 unfreeze, meantime restore to previous behavior by keeping queue\nquiesced during suspend.",
"id": "GHSA-hgm3-gq5f-vjwg",
"modified": "2025-11-03T21:32:15Z",
"published": "2025-01-21T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57946"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5"
},
{
"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"
}
]
}
GHSA-HH52-G3XV-6XXC
Vulnerability from github – Published: 2022-03-26 00:00 – Updated: 2024-04-01 15:30A flaw was found in the libvirt libxl driver. A malicious guest could continuously reboot itself and cause libvirtd on the host to deadlock or crash, resulting in a denial of service condition.
{
"affected": [],
"aliases": [
"CVE-2021-4147"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-25T19:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the libvirt libxl driver. A malicious guest could continuously reboot itself and cause libvirtd on the host to deadlock or crash, resulting in a denial of service condition.",
"id": "GHSA-hh52-g3xv-6xxc",
"modified": "2024-04-01T15:30:28Z",
"published": "2022-03-26T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4147"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2034195"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00000.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220513-0004"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HH6Q-PGH2-779F
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2025-02-14 18:30In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the priv->lock while iterating the priv->multicast_list in
ipoib_mcast_join_task() opens a window for ipoib_mcast_dev_flush() to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, mcast is no longer on the | list_for_each_entry_safe(mcast, tmcast,
priv->multicast_list and we keep | remove_list, list)
spinning on the remove_list of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups.
crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2" -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty)
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000
crash> b 8 PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0" -- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52587"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/ipoib: Fix mcast list locking\n\nReleasing the `priv-\u003elock` while iterating the `priv-\u003emulticast_list` in\n`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to\nremove the items while in the middle of iteration. If the mcast is removed\nwhile the lock was dropped, the for loop spins forever resulting in a hard\nlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):\n\n Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)\n -----------------------------------+-----------------------------------\n ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)\n spin_lock_irq(\u0026priv-\u003elock) | __ipoib_ib_dev_flush(priv, ...)\n list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv-\u003edev)\n \u0026priv-\u003emulticast_list, list) |\n ipoib_mcast_join(dev, mcast) |\n spin_unlock_irq(\u0026priv-\u003elock) |\n | spin_lock_irqsave(\u0026priv-\u003elock, flags)\n | list_for_each_entry_safe(mcast, tmcast,\n | \u0026priv-\u003emulticast_list, list)\n | list_del(\u0026mcast-\u003elist);\n | list_add_tail(\u0026mcast-\u003elist, \u0026remove_list)\n | spin_unlock_irqrestore(\u0026priv-\u003elock, flags)\n spin_lock_irq(\u0026priv-\u003elock) |\n | ipoib_mcast_remove_list(\u0026remove_list)\n (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,\n `priv-\u003emulticast_list` and we keep | remove_list, list)\n spinning on the `remove_list` of | \u003e\u003e\u003e wait_for_completion(\u0026mcast-\u003edone)\n the other thread which is blocked |\n and the list is still valid on |\n it\u0027s stack.)\n\nFix this by keeping the lock held and changing to GFP_ATOMIC to prevent\neventual sleeps.\nUnfortunately we could not reproduce the lockup and confirm this fix but\nbased on the code review I think this fix should address such lockups.\n\ncrash\u003e bc 31\nPID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: \"kworker/u72:2\"\n--\n [exception RIP: ipoib_mcast_join_task+0x1b1]\n RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002\n RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000\n work (\u0026priv-\u003emcast_task{,.work})\n RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000\n \u0026mcast-\u003elist\n RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000\n R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00\n mcast\n R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8\n dev priv (\u0026priv-\u003elock) \u0026priv-\u003emulticast_list (aka head)\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n--- \u003cNMI exception stack\u003e ---\n #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]\n #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967\n\ncrash\u003e rx ff646f199a8c7e68\nff646f199a8c7e68: ff1c6a1a04dc82f8 \u003c\u003c\u003c work = \u0026priv-\u003emcast_task.work\n\ncrash\u003e list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000\n(empty)\n\ncrash\u003e ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000\n mcast_task.work.func = 0xffffffffc0944910 \u003cipoib_mcast_join_task\u003e,\n mcast_mutex.owner.counter = 0xff1c69998efec000\n\ncrash\u003e b 8\nPID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: \"kworker/u72:0\"\n--\n #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646\n #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]\n #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]\n #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]\n #7 [ff\n---truncated---",
"id": "GHSA-hh6q-pgh2-779f",
"modified": "2025-02-14T18:30:44Z",
"published": "2024-03-06T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52587"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34"
},
{
"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:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HH73-MJW2-25FW
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [] nj_release+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] mightsleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? flush_work+0x20/0x20 [ 44.178257 ] ? lock_release+0x13c/0x8f0 [ 44.178550 ] ? __kasan_check_write+0x14/0x20 [ 44.178872 ] ? do_raw_spin_lock+0x148/0x360 [ 44.179187 ] ? read_lock_is_recursive+0x20/0x20 [ 44.179530 ] ? __kasan_check_read+0x11/0x20 [ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900 [ 44.180168 ] ? ____kasan_slab_free+0x116/0x140 [ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60 [ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 ] nj_release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/0x70 [netjet] [ 44.182989 ] pci_device_remove+0xa9/0x250
{
"affected": [],
"aliases": [
"CVE-2021-47468"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T07:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: Fix sleeping function called from invalid context\n\nThe driver can call card-\u003eisac.release() function from an atomic\ncontext.\n\nFix this by calling this function after releasing the lock.\n\nThe following log reveals it:\n\n[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[ 44.169574 ] INFO: lockdep is turned off.\n[ 44.169899 ] irq event stamp: 0\n[ 44.170160 ] hardirqs last enabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 44.170627 ] hardirqs last disabled at (0): [\u003cffffffff814209ed\u003e] copy_process+0x132d/0x3e00\n[ 44.171240 ] softirqs last enabled at (0): [\u003cffffffff81420a1a\u003e] copy_process+0x135a/0x3e00\n[ 44.171852 ] softirqs last disabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 44.172318 ] Preemption disabled at:\n[ 44.172320 ] [\u003cffffffffa009b0a9\u003e] nj_release+0x69/0x500 [netjet]\n[ 44.174441 ] Call Trace:\n[ 44.174630 ] dump_stack_lvl+0xa8/0xd1\n[ 44.174912 ] dump_stack+0x15/0x17\n[ 44.175166 ] ___might_sleep+0x3a2/0x510\n[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]\n[ 44.175791 ] __might_sleep+0x82/0xe0\n[ 44.176063 ] ? start_flush_work+0x20/0x7b0\n[ 44.176375 ] start_flush_work+0x33/0x7b0\n[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170\n[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177711 ] __flush_work+0x11a/0x1a0\n[ 44.177991 ] ? flush_work+0x20/0x20\n[ 44.178257 ] ? lock_release+0x13c/0x8f0\n[ 44.178550 ] ? __kasan_check_write+0x14/0x20\n[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360\n[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20\n[ 44.179530 ] ? __kasan_check_read+0x11/0x20\n[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900\n[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140\n[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60\n[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0\n[ 44.181189 ] ? kfree+0x13e/0x290\n[ 44.181438 ] flush_work+0x17/0x20\n[ 44.181695 ] mISDN_freedchannel+0xe8/0x100\n[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]\n[ 44.182366 ] nj_release+0xf6/0x500 [netjet]\n[ 44.182685 ] nj_remove+0x48/0x70 [netjet]\n[ 44.182989 ] pci_device_remove+0xa9/0x250",
"id": "GHSA-hh73-mjw2-25fw",
"modified": "2025-09-24T21:30:30Z",
"published": "2024-05-22T09:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37e4f57b22cc5ebb3f80cf0f74fdeb487f082367"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4054b869dc263228d30a4755800b78f0f2ba0c89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6510e80a0b81b5d814e3aea6297ba42f5e76f73c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f95c97e0f9d6eb39c3f2cb45e8fa4268d1b372b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f591cbdbed3d7822b2bdba89b34a6d7b434317d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b34409d3fc52114c828be4adbc30744fa3258b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef269a8808cb1759245a98a7fe16fceaebad894c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5966ba53013149bcf94e1536644a958dd00a026"
}
],
"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-HHXW-8C9W-Q5Q9
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-06-29 00:00A local privilege escalation was discovered in the Linux kernel before 5.10.13. Multiple race conditions in the AF_VSOCK implementation are caused by wrong locking in net/vmw_vsock/af_vsock.c. The race conditions were implicitly introduced in the commits that added VSOCK multi-transport support.
{
"affected": [],
"aliases": [
"CVE-2021-26708"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-05T14:15:00Z",
"severity": "HIGH"
},
"details": "A local privilege escalation was discovered in the Linux kernel before 5.10.13. Multiple race conditions in the AF_VSOCK implementation are caused by wrong locking in net/vmw_vsock/af_vsock.c. The race conditions were implicitly introduced in the commits that added VSOCK multi-transport support.",
"id": "GHSA-hhxw-8c9w-q5q9",
"modified": "2022-06-29T00:00:48Z",
"published": "2022-05-24T17:41:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26708"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c518adafa39f37858697ac9309c6cf1805581446"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210312-0008"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2021/02/04/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/02/05/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/04/09/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/25/14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJ3C-GWRC-6JCH
Vulnerability from github – Published: 2024-07-30 09:31 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31.
We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-42114"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\n\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\n\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\"pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\")\n\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last enabled at (131134): [\u003cffff80008ae8778c\u003e] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last enabled at (131134): [\u003cffff80008ae8778c\u003e] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u003cffff80008ae85378\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u003cffff80008ae85378\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (125892): [\u003cffff80008907e82c\u003e] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last enabled at (125892): [\u003cffff80008907e82c\u003e] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u003cffff80008904166c\u003e] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n __list_del include/linux/list.h:195 [inline]\n __list_del_entry include/linux/list.h:218 [inline]\n list_move_tail include/linux/list.h:310 [inline]\n fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n wake_tx_push_queue net/mac80211/util.c:294 [inline]\n ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_fini\n---truncated---",
"id": "GHSA-hj3c-gwrc-6jch",
"modified": "2026-05-12T12:32:03Z",
"published": "2024-07-30T09:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42114"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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-HJGX-24CQ-764X
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-19 18:31In the Linux kernel, the following vulnerability has been resolved:
procfs: avoid fetching build ID while holding VMA lock
Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:
-> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}: __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8);
*** DEADLOCK ***
This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:
777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")
To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly.
[akpm@linux-foundation.org: fix up kerneldoc]
{
"affected": [],
"aliases": [
"CVE-2026-23199"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T17:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -\u003e #1 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\n __might_fault+0xed/0x170\n _copy_to_iter+0x118/0x1720\n copy_page_to_iter+0x12d/0x1e0\n filemap_read+0x720/0x10a0\n blkdev_read_iter+0x2b5/0x4e0\n vfs_read+0x7f4/0xae0\n ksys_read+0x12a/0x250\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -\u003e #0 (\u0026sb-\u003es_type-\u003ei_mutex_key#8){++++}-{4:4}:\n __lock_acquire+0x1509/0x26d0\n lock_acquire+0x185/0x340\n down_read+0x98/0x490\n blkdev_read_iter+0x2a7/0x4e0\n __kernel_read+0x39a/0xa90\n freader_fetch+0x1d5/0xa80\n __build_id_parse.isra.0+0xea/0x6a0\n do_procmap_query+0xd75/0x1050\n procfs_procmap_ioctl+0x7a/0xb0\n __x64_sys_ioctl+0x18e/0x210\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n rlock(\u0026mm-\u003emmap_lock);\n lock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n lock(\u0026mm-\u003emmap_lock);\n rlock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n\n *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven\u0027t seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]",
"id": "GHSA-hjgx-24cq-764x",
"modified": "2026-03-19T18:31:14Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08"
}
],
"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.