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-HC84-56CX-WR29
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix softlockup in arena_map_free on 64k page kernel
On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y, arena_htab tests cause a segmentation fault and soft lockup. The same failure is not observed with 4k pages on aarch64.
It turns out arena_map_free() is calling apply_to_existing_page_range() with the address returned by bpf_arena_get_kern_vm_start(). If this address is not page-aligned the code ends up calling apply_to_pte_range() with that unaligned address causing soft lockup.
Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that the division by 2 in bpf_arena_get_kern_vm_start() returns a page-aligned value.
{
"affected": [],
"aliases": [
"CVE-2025-21851"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:17Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix softlockup in arena_map_free on 64k page kernel\n\nOn an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,\narena_htab tests cause a segmentation fault and soft lockup.\nThe same failure is not observed with 4k pages on aarch64.\n\nIt turns out arena_map_free() is calling\napply_to_existing_page_range() with the address returned by\nbpf_arena_get_kern_vm_start(). If this address is not page-aligned\nthe code ends up calling apply_to_pte_range() with that unaligned\naddress causing soft lockup.\n\nFix it by round up GUARD_SZ to PAGE_SIZE \u003c\u003c 1 so that the\ndivision by 2 in bpf_arena_get_kern_vm_start() returns\na page-aligned value.",
"id": "GHSA-hc84-56cx-wr29",
"modified": "2025-03-13T18:32:21Z",
"published": "2025-03-12T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21851"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/517e8a7835e8cfb398a0aeb0133de50e31cae32b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/787d556a3de447e70964a4bdeba9196f62a62b1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1f3f3892d4526f18aaeffdb6068ce861e793ee3"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-HC99-RGJ6-64QJ
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid journal no-space deadlock by reserving 1 journal bucket
The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation.
When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens.
The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore.
This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time.
During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49327"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: avoid journal no-space deadlock by reserving 1 journal bucket\n\nThe journal no-space deadlock was reported time to time. Such deadlock\ncan happen in the following situation.\n\nWhen all journal buckets are fully filled by active jset with heavy\nwrite I/O load, the cache set registration (after a reboot) will load\nall active jsets and inserting them into the btree again (which is\ncalled journal replay). If a journaled bkey is inserted into a btree\nnode and results btree node split, new journal request might be\ntriggered. For example, the btree grows one more level after the node\nsplit, then the root node record in cache device super block will be\nupgrade by bch_journal_meta() from bch_btree_set_root(). But there is no\nspace in journal buckets, the journal replay has to wait for new journal\nbucket to be reclaimed after at least one journal bucket replayed. This\nis one example that how the journal no-space deadlock happens.\n\nThe solution to avoid the deadlock is to reserve 1 journal bucket in\nrun time, and only permit the reserved journal bucket to be used during\ncache set registration procedure for things like journal replay. Then\nthe journal space will never be fully filled, there is no chance for\njournal no-space deadlock to happen anymore.\n\nThis patch adds a new member \"bool do_reserve\" in struct journal, it is\ninititalized to 0 (false) when struct journal is allocated, and set to\n1 (true) by bch_journal_space_reserve() when all initialization done in\nrun_cache_set(). In the run time when journal_reclaim() tries to\nallocate a new journal bucket, free_journal_buckets() is called to check\nwhether there are enough free journal buckets to use. If there is only\n1 free journal bucket and journal-\u003edo_reserve is 1 (true), the last\nbucket is reserved and free_journal_buckets() will return 0 to indicate\nno free journal bucket. Then journal_reclaim() will give up, and try\nnext time to see whetheer there is free journal bucket to allocate. By\nthis method, there is always 1 jouranl bucket reserved in run time.\n\nDuring the cache set registration, journal-\u003edo_reserve is 0 (false), so\nthe reserved journal bucket can be used to avoid the no-space deadlock.",
"id": "GHSA-hc99-rgj6-64qj",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49327"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497"
}
],
"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-HFFQ-87G8-8R3X
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
padata: Always leave BHs disabled when running ->parallel()
A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task:
padata_do_parallel
->parallel()
pcrypt_aead_enc/dec
padata_do_serial
spin_lock(&reorder->lock) // BHs still enabled
<interrupt>
...
__do_softirq
...
padata_do_serial
spin_lock(&reorder->lock)
It's a bug for BHs to be on in _do_serial as Steffen points out, so ensure they're off in the "current task" case like they are in padata_parallel_worker to avoid this situation.
{
"affected": [],
"aliases": [
"CVE-2022-50382"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Always leave BHs disabled when running -\u003eparallel()\n\nA deadlock can happen when an overloaded system runs -\u003eparallel() in the\ncontext of the current task:\n\n padata_do_parallel\n -\u003eparallel()\n pcrypt_aead_enc/dec\n padata_do_serial\n spin_lock(\u0026reorder-\u003elock) // BHs still enabled\n \u003cinterrupt\u003e\n ...\n __do_softirq\n ...\n padata_do_serial\n spin_lock(\u0026reorder-\u003elock)\n\nIt\u0027s a bug for BHs to be on in _do_serial as Steffen points out, so\nensure they\u0027re off in the \"current task\" case like they are in\npadata_parallel_worker to avoid this situation.",
"id": "GHSA-hffq-87g8-8r3x",
"modified": "2025-12-11T18:30:33Z",
"published": "2025-09-18T15:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50382"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17afa98bccec4f52203508b3f49b5f948c6fd6ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34c3a47d20ae55b3600fed733bf96eafe9c500d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cfa9e60c0f88fdec6368e081ab968411cc706b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7337adb20fcc0aebb50eaff2bc5a8dd9a7c6743d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e0681dd4eee029eb1d533d06993f7cb091efb73"
}
],
"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-HFJ6-RQ3W-F48R
Vulnerability from github – Published: 2022-02-11 00:01 – Updated: 2023-08-08 15:31Improper locking in the Power Management Controller (PMC) for some Intel Chipset firmware before versions pmc_fw_lbg_c1-21ww02a and pmc_fw_lbg_b0-21ww02a may allow a privileged user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0147"
],
"database_specific": {
"cwe_ids": [
"CWE-662",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "Improper locking in the Power Management Controller (PMC) for some Intel Chipset firmware before versions pmc_fw_lbg_c1-21ww02a and pmc_fw_lbg_b0-21ww02a may allow a privileged user to potentially enable denial of service via local access.",
"id": "GHSA-hfj6-rq3w-f48r",
"modified": "2023-08-08T15:31:43Z",
"published": "2022-02-11T00:01:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0147"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00470.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HFM8-Q4MR-MF9F
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2025-11-18 18:32In the Linux kernel, the following vulnerability has been resolved:
virtio-net: fix recursived rtnl_lock() during probe()
The deadlock appears in a stack trace like:
virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock()
It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing.
The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().
{
"affected": [],
"aliases": [
"CVE-2025-38551"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T12:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: fix recursived rtnl_lock() during probe()\n\nThe deadlock appears in a stack trace like:\n\n virtnet_probe()\n rtnl_lock()\n virtio_config_changed_work()\n netdev_notify_peers()\n rtnl_lock()\n\nIt happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the\nvirtio-net driver is still probing.\n\nThe config_work in probe() will get scheduled until virtnet_open() enables\nthe config change notification via virtio_config_driver_enable().",
"id": "GHSA-hfm8-q4mr-mf9f",
"modified": "2025-11-18T18:32:49Z",
"published": "2025-08-16T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3859f137b3c1fa1f0031d54263234566bdcdd7aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e7c46362550b229354aeb52038f414e231b0037"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5dcaed694e4255dc02dd0acfe036708c535def"
}
],
"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-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"
}
]
}
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.