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-8W9J-8C65-FRH3
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2026-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Don't call mmput from MMU notifier callback
If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace.
The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking.
The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work.
If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child.
The backtrace of hung task:
INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu]
(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
{
"affected": [],
"aliases": [
"CVE-2025-38520"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T11:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Don\u0027t call mmput from MMU notifier callback\n\nIf the process is exiting, the mmput inside mmu notifier callback from\ncompactd or fork or numa balancing could release the last reference\nof mm struct to call exit_mmap and free_pgtable, this triggers deadlock\nwith below backtrace.\n\nThe deadlock will leak kfd process as mmu notifier release is not called\nand cause VRAM leaking.\n\nThe fix is to take mm reference mmget_non_zero when adding prange to the\ndeferred list to pair with mmput in deferred list work.\n\nIf prange split and add into pchild list, the pchild work_item.mm is not\nused, so remove the mm parameter from svm_range_unmap_split and\nsvm_range_add_child.\n\nThe backtrace of hung task:\n\n INFO: task python:348105 blocked for more than 64512 seconds.\n Call Trace:\n __schedule+0x1c3/0x550\n schedule+0x46/0xb0\n rwsem_down_write_slowpath+0x24b/0x4c0\n unlink_anon_vmas+0xb1/0x1c0\n free_pgtables+0xa9/0x130\n exit_mmap+0xbc/0x1a0\n mmput+0x5a/0x140\n svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]\n mn_itree_invalidate+0x72/0xc0\n __mmu_notifier_invalidate_range_start+0x48/0x60\n try_to_unmap_one+0x10fa/0x1400\n rmap_walk_anon+0x196/0x460\n try_to_unmap+0xbb/0x210\n migrate_page_unmap+0x54d/0x7e0\n migrate_pages_batch+0x1c3/0xae0\n migrate_pages_sync+0x98/0x240\n migrate_pages+0x25c/0x520\n compact_zone+0x29d/0x590\n compact_zone_order+0xb6/0xf0\n try_to_compact_pages+0xbe/0x220\n __alloc_pages_direct_compact+0x96/0x1a0\n __alloc_pages_slowpath+0x410/0x930\n __alloc_pages_nodemask+0x3a9/0x3e0\n do_huge_pmd_anonymous_page+0xd7/0x3e0\n __handle_mm_fault+0x5e3/0x5f0\n handle_mm_fault+0xf7/0x2e0\n hmm_vma_fault.isra.0+0x4d/0xa0\n walk_pmd_range.isra.0+0xa8/0x310\n walk_pud_range+0x167/0x240\n walk_pgd_range+0x55/0x100\n __walk_page_range+0x87/0x90\n walk_page_range+0xf6/0x160\n hmm_range_fault+0x4f/0x90\n amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]\n amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]\n init_user_pages+0xb1/0x2a0 [amdgpu]\n amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]\n kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]\n kfd_ioctl+0x29d/0x500 [amdgpu]\n\n(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)",
"id": "GHSA-8w9j-8c65-frh3",
"modified": "2026-01-07T18:30:19Z",
"published": "2025-08-16T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38520"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/145a56bd68f4bff098d59fbc7c263d20dfef4fc4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7eb0a25010a674c8fdfbece38353ef7be8c5834"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1bde9d48e09933c361521720f77a8072083c83a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf234231fcbc7d391e2135b9518613218cc5347f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e90ee15ce28c61f6d83a0511c3e02e2662478350"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-8WHV-9RRR-8P39
Vulnerability from github – Published: 2022-01-20 00:01 – Updated: 2022-01-27 00:03An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series and SRX Series allows an unauthenticated networked attacker to cause a flowprocessing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue can occur in a scenario where the SIP ALG is enabled and specific SIP messages are being processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R1-S2, 21.2R2; 21.3 versions prior to 21.3R1-S1, 21.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1.
{
"affected": [],
"aliases": [
"CVE-2022-22175"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-19T01:15:00Z",
"severity": "HIGH"
},
"details": "An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series and SRX Series allows an unauthenticated networked attacker to cause a flowprocessing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue can occur in a scenario where the SIP ALG is enabled and specific SIP messages are being processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R1-S2, 21.2R2; 21.3 versions prior to 21.3R1-S1, 21.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1.",
"id": "GHSA-8whv-9rrr-8p39",
"modified": "2022-01-27T00:03:42Z",
"published": "2022-01-20T00:01:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22175"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11281"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-92W6-8752-JF23
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36In priorLinearAllocation of C2AllocatorIon.cpp, there is a possible use-after-free due to improper locking. This could lead to local information disclosure in the media codec with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-152239213
{
"affected": [],
"aliases": [
"CVE-2020-27035"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "In priorLinearAllocation of C2AllocatorIon.cpp, there is a possible use-after-free due to improper locking. This could lead to local information disclosure in the media codec with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-152239213",
"id": "GHSA-92w6-8752-jf23",
"modified": "2022-05-24T17:36:30Z",
"published": "2022-05-24T17:36:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27035"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2020-12-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-934P-M4FH-22Q3
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
ext4: do not create EA inode under buffer lock
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers.
{
"affected": [],
"aliases": [
"CVE-2024-40972"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: do not create EA inode under buffer lock\n\next4_xattr_set_entry() creates new EA inodes while holding buffer lock\non the external xattr block. This is problematic as it nests all the\nallocation locking (which acquires locks on other buffers) under the\nbuffer lock. This can even deadlock when the filesystem is corrupted and\ne.g. quota file is setup to contain xattr block as data block. Move the\nallocation of EA inode out of ext4_xattr_set_entry() into the callers.",
"id": "GHSA-934p-m4fh-22q3",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40972"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1"
},
{
"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-93XM-X65X-HGXH
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: Fix the potential deadlock
When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock.
Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here.
Process A Process B
process_scheduled_works()
pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock);
pdr_locate_service() mutex_lock(&pdr->list_lock);
pdr_get_domain_list()
pr_err("PDR: %s get domain list
txn wait failed: %d\n",
req->service_name,
ret);
Timeout error log due to deadlock:
" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 "
Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1]
{
"affected": [],
"aliases": [
"CVE-2025-22014"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pdr: Fix the potential deadlock\n\nWhen some client process A call pdr_add_lookup() to add the look up for\nthe service and does schedule locator work, later a process B got a new\nserver packet indicating locator is up and call pdr_locator_new_server()\nwhich eventually sets pdr-\u003elocator_init_complete to true which process A\nsees and takes list lock and queries domain list but it will timeout due\nto deadlock as the response will queued to the same qmi-\u003ewq and it is\nordered workqueue and process B is not able to complete new server\nrequest work due to deadlock on list lock.\n\nFix it by removing the unnecessary list iteration as the list iteration\nis already being done inside locator work, so avoid it here and just\ncall schedule_work() here.\n\n Process A Process B\n\n process_scheduled_works()\npdr_add_lookup() qmi_data_ready_work()\n process_scheduled_works() pdr_locator_new_server()\n pdr-\u003elocator_init_complete=true;\n pdr_locator_work()\n mutex_lock(\u0026pdr-\u003elist_lock);\n\n pdr_locate_service() mutex_lock(\u0026pdr-\u003elist_lock);\n\n pdr_get_domain_list()\n pr_err(\"PDR: %s get domain list\n txn wait failed: %d\\n\",\n req-\u003eservice_name,\n ret);\n\nTimeout error log due to deadlock:\n\n\"\n PDR: tms/servreg get domain list txn wait failed: -110\n PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110\n\"\n\nThanks to Bjorn and Johan for letting me know that this commit also fixes\nan audio regression when using the in-kernel pd-mapper as that makes it\neasier to hit this race. [1]",
"id": "GHSA-93xm-x65x-hgxh",
"modified": "2025-11-03T21:33:30Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22014"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02612f1e4c34d94d6c8ee75bf7d254ed697e22d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a566a79aca9851fae140536e0fc5b0853c90a90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2eeb03ad9f42dfece63051be2400af487ddb96d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/daba84612236de3ab39083e62c9e326a654ebd20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2bbfd50e95bc117360f0f59e629aa03d821ebd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4489260f5713c94e1966e5f20445bff262876f4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-94F3-Q8QM-3FQ6
Vulnerability from github – Published: 2022-05-02 03:19 – Updated: 2024-02-09 03:32The inotify_read function in the Linux kernel 2.6.27 to 2.6.27.13, 2.6.28 to 2.6.28.2, and 2.6.29-rc3 allows local users to cause a denial of service (OOPS) via a read with an invalid address to an inotify instance, which causes the device's event list mutex to be unlocked twice and prevents proper synchronization of a data structure for the inotify instance.
{
"affected": [],
"aliases": [
"CVE-2009-0935"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-03-18T02:00:00Z",
"severity": "MODERATE"
},
"details": "The inotify_read function in the Linux kernel 2.6.27 to 2.6.27.13, 2.6.28 to 2.6.28.2, and 2.6.29-rc3 allows local users to cause a denial of service (OOPS) via a read with an invalid address to an inotify instance, which causes the device\u0027s event list mutex to be unlocked twice and prevents proper synchronization of a data structure for the inotify instance.",
"id": "GHSA-94f3-q8qm-3fq6",
"modified": "2024-02-09T03:32:54Z",
"published": "2022-05-02T03:19:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0935"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=488935"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49331"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=123337123501681\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28.3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/06/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/18/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/19/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/33624"
}
],
"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-94MC-R26H-RWJ7
Vulnerability from github – Published: 2025-02-09 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity()
The following call-chain leads to enabling interrupts in a nested interrupt disabled section:
irq_set_vcpu_affinity() irq_get_desc_lock() raw_spin_lock_irqsave() <--- Disable interrupts its_irq_set_vcpu_affinity() guard(raw_spinlock_irq) <--- Enables interrupts when leaving the guard() irq_put_desc_unlock() <--- Warns because interrupts are enabled
This was broken in commit b97e8a2f7130, which replaced the original raw_spin_[un]lock() pair with guard(raw_spinlock_irq).
Fix the issue by using guard(raw_spinlock).
[ tglx: Massaged change log ]
{
"affected": [],
"aliases": [
"CVE-2024-57949"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-09T12:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Don\u0027t enable interrupts in its_irq_set_vcpu_affinity()\n\nThe following call-chain leads to enabling interrupts in a nested interrupt\ndisabled section:\n\nirq_set_vcpu_affinity()\n irq_get_desc_lock()\n raw_spin_lock_irqsave() \u003c--- Disable interrupts\n its_irq_set_vcpu_affinity()\n guard(raw_spinlock_irq) \u003c--- Enables interrupts when leaving the guard()\n irq_put_desc_unlock() \u003c--- Warns because interrupts are enabled\n\nThis was broken in commit b97e8a2f7130, which replaced the original\nraw_spin_[un]lock() pair with guard(raw_spinlock_irq).\n\nFix the issue by using guard(raw_spinlock).\n\n[ tglx: Massaged change log ]",
"id": "GHSA-94mc-r26h-rwj7",
"modified": "2025-11-03T21:32:35Z",
"published": "2025-02-09T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57949"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35cb2c6ce7da545f3b5cb1e6473ad7c3a6f08310"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c84ff2e788fce0099ee3e71a3ed258b1ca1a223"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93955a7788121ab5a0f7f27e988b2ed1135a4866"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7b0e89610dd45ac6cf0d6f99bfa9ccc787db344"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/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-94VP-7849-58R6
Vulnerability from github – Published: 2025-01-31 12:33 – Updated: 2025-02-03 21:31In the Linux kernel, the following vulnerability has been resolved:
afs: Fix merge preference rule failure condition
syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released.
Fix this by store the error in ret and jump to done to clean up instead of returning directly.
[dh: Modified Lizhi Xu's original patch to make it honour the error code from afs_split_string()]
[1] WARNING: lock held when returning to user space! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted
syz-executor133/5823 is leaving the kernel with locks still held! 1 lock held by syz-executor133/5823: #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline] #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388
{
"affected": [],
"aliases": [
"CVE-2025-21672"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T12:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix merge preference rule failure condition\n\nsyzbot reported a lock held when returning to userspace[1]. This is\nbecause if argc is less than 0 and the function returns directly, the held\ninode lock is not released.\n\nFix this by store the error in ret and jump to done to clean up instead of\nreturning directly.\n\n[dh: Modified Lizhi Xu\u0027s original patch to make it honour the error code\nfrom afs_split_string()]\n\n[1]\nWARNING: lock held when returning to user space!\n6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted\n------------------------------------------------\nsyz-executor133/5823 is leaving the kernel with locks still held!\n1 lock held by syz-executor133/5823:\n #0: ffff888071cffc00 (\u0026sb-\u003es_type-\u003ei_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline]\n #0: ffff888071cffc00 (\u0026sb-\u003es_type-\u003ei_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388",
"id": "GHSA-94vp-7849-58r6",
"modified": "2025-02-03T21:31:49Z",
"published": "2025-01-31T12:33:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21672"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17a4fde81d3a7478d97d15304a6d61094a10c2e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22be1d90a6211c88dd093b25d1f3aa974d0d9f9d"
}
],
"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-95MR-34PQ-HC3C
Vulnerability from github – Published: 2024-08-22 06:30 – Updated: 2024-08-23 03:30In the Linux kernel, the following vulnerability has been resolved:
RDMA/ib_srp: Fix a deadlock
Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync()
{
"affected": [],
"aliases": [
"CVE-2022-48930"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T04:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ib_srp: Fix a deadlock\n\nRemove the flush_workqueue(system_long_wq) call since flushing\nsystem_long_wq is deadlock-prone and since that call is redundant with a\npreceding cancel_work_sync()",
"id": "GHSA-95mr-34pq-hc3c",
"modified": "2024-08-23T03:30:59Z",
"published": "2024-08-22T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48930"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/081bdc9fe05bb23248f5effb6f811da3da4b8252"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190dfb1b27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51"
}
],
"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-96WF-6GFH-Q6GV
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2025-11-25 18:32In the Linux kernel, the following vulnerability has been resolved:
dm: dm-crypt: Do not partially accept write BIOs with zoned targets
Read and write operations issued to a dm-crypt target may be split according to the dm-crypt internal limits defined by the max_read_size and max_write_size module parameters (default is 128 KB). The intent is to improve processing time of large BIOs by splitting them into smaller operations that can be parallelized on different CPUs.
For zoned dm-crypt targets, this BIO splitting is still done but without the parallel execution to ensure that the issuing order of write operations to the underlying devices remains sequential. However, the splitting itself causes other problems:
1) Since dm-crypt relies on the block layer zone write plugging to handle zone append emulation using regular write operations, the reminder of a split write BIO will always be plugged into the target zone write plugged. Once the on-going write BIO finishes, this reminder BIO is unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be re-issued and plugged again, but that causes a call to a blk_queue_enter(), which may block if a queue freeze operation was initiated. This results in a deadlock as DM submission still holds BIOs that the queue freeze side is waiting for.
2) dm-crypt relies on the emulation done by the block layer using regular write operations for processing zone append operations. This still requires to properly return the written sector as the BIO sector of the original BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original zone append operation issued by the user. If the size of a zone append operation is larger than dm-crypt max_write_size, then the orginal BIO will be split and processed as a chain of regular write operations. Such chaining result in an incorrect written sector being returned to the zone append issuer using the original BIO sector. This in turn results in file system data corruptions using xfs or btrfs.
Fix this by modifying get_max_request_size() to always return the size of the BIO to avoid it being split with dm_accpet_partial_bio() in crypt_map(). get_max_request_size() is renamed to get_max_request_sectors() to clarify the unit of the value returned and its interface is changed to take a struct dm_target pointer and a pointer to the struct bio being processed. In addition to this change, to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt device max_hw_sectors limit to be at most BIO_MAX_VECS << PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture). This forces DM core to split write BIOs before passing them to crypt_map(), and thus guaranteeing that dm-crypt can always accept an entire write BIO without needing to split it.
This change does not have any effect on the read path of dm-crypt. Read operations can still be split and the BIO fragments processed in parallel. There is also no impact on the performance of the write path given that all zone write BIOs were already processed inline instead of in parallel.
This change also does not affect in any way regular dm-crypt block devices.
{
"affected": [],
"aliases": [
"CVE-2025-39791"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm: dm-crypt: Do not partially accept write BIOs with zoned targets\n\nRead and write operations issued to a dm-crypt target may be split\naccording to the dm-crypt internal limits defined by the max_read_size\nand max_write_size module parameters (default is 128 KB). The intent is\nto improve processing time of large BIOs by splitting them into smaller\noperations that can be parallelized on different CPUs.\n\nFor zoned dm-crypt targets, this BIO splitting is still done but without\nthe parallel execution to ensure that the issuing order of write\noperations to the underlying devices remains sequential. However, the\nsplitting itself causes other problems:\n\n1) Since dm-crypt relies on the block layer zone write plugging to\n handle zone append emulation using regular write operations, the\n reminder of a split write BIO will always be plugged into the target\n zone write plugged. Once the on-going write BIO finishes, this\n reminder BIO is unplugged and issued from the zone write plug work.\n If this reminder BIO itself needs to be split, the reminder will be\n re-issued and plugged again, but that causes a call to a\n blk_queue_enter(), which may block if a queue freeze operation was\n initiated. This results in a deadlock as DM submission still holds\n BIOs that the queue freeze side is waiting for.\n\n2) dm-crypt relies on the emulation done by the block layer using\n regular write operations for processing zone append operations. This\n still requires to properly return the written sector as the BIO\n sector of the original BIO. However, this can be done correctly only\n and only if there is a single clone BIO used for processing the\n original zone append operation issued by the user. If the size of a\n zone append operation is larger than dm-crypt max_write_size, then\n the orginal BIO will be split and processed as a chain of regular\n write operations. Such chaining result in an incorrect written sector\n being returned to the zone append issuer using the original BIO\n sector. This in turn results in file system data corruptions using\n xfs or btrfs.\n\nFix this by modifying get_max_request_size() to always return the size\nof the BIO to avoid it being split with dm_accpet_partial_bio() in\ncrypt_map(). get_max_request_size() is renamed to\nget_max_request_sectors() to clarify the unit of the value returned\nand its interface is changed to take a struct dm_target pointer and a\npointer to the struct bio being processed. In addition to this change,\nto ensure that crypt_alloc_buffer() works correctly, set the dm-crypt\ndevice max_hw_sectors limit to be at most\nBIO_MAX_VECS \u003c\u003c PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture).\nThis forces DM core to split write BIOs before passing them to\ncrypt_map(), and thus guaranteeing that dm-crypt can always accept an\nentire write BIO without needing to split it.\n\nThis change does not have any effect on the read path of dm-crypt. Read\noperations can still be split and the BIO fragments processed in\nparallel. There is also no impact on the performance of the write path\ngiven that all zone write BIOs were already processed inline instead of\nin parallel.\n\nThis change also does not affect in any way regular dm-crypt block\ndevices.",
"id": "GHSA-96wf-6gfh-q6gv",
"modified": "2025-11-25T18:32:20Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39791"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52a2c4c60470352acf9cde7a2dfa661c1e67e796"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8864616719b6bbf92356bc89ff544b0cd484c656"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e549663849e5bb3b985dc2d293069f0d9747ae72"
}
],
"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.