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-FGCR-GVFF-J4CQ
Vulnerability from github – Published: 2022-05-01 02:14 – Updated: 2024-02-15 21:31Race condition in Linux 2.6, when threads are sharing memory mapping via CLONE_VM (such as linuxthreads and vfork), might allow local users to cause a denial of service (deadlock) by triggering a core dump while waiting for a thread that has just performed an exec.
{
"affected": [],
"aliases": [
"CVE-2005-3106"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-09-30T10:05:00Z",
"severity": "LOW"
},
"details": "Race condition in Linux 2.6, when threads are sharing memory mapping via CLONE_VM (such as linuxthreads and vfork), might allow local users to cause a denial of service (deadlock) by triggering a core dump while waiting for a thread that has just performed an exec.",
"id": "GHSA-fgcr-gvff-j4cq",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T02:14:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-3106"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A9108"
},
{
"type": "WEB",
"url": "http://linux.bkbits.net:8080/linux-2.6/diffs/fs/exec.c%401.156?nav=index.html%7Csrc/%7Csrc/fs%7Chist/fs/exec.c"
},
{
"type": "WEB",
"url": "http://linux.bkbits.net:8080/linux-2.6/diffs/fs/exec.c@1.156?nav=index.html|src/|src/fs|hist/fs/exec.c"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17141"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18056"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18510"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-922"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2006:072"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2006-0101.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/427980/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/15049"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-199-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FGFP-PP34-JXVV
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix possible deadlocks
This fixes possible deadlocks like the following caused by hci_cmd_sync_dequeue causing the destroy function to run:
INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30 __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80 [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth] __mgmt_power_off+0x8d/0x180 [bluetooth] ? _raw_spin_unlock_irq+0x23/0x40 hci_dev_close_sync+0x445/0x5b0 [bluetooth] hci_set_powered_sync+0x149/0x250 [bluetooth] set_powered_sync+0x24/0x60 [bluetooth] hci_cmd_sync_work+0x90/0x150 [bluetooth] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
{
"affected": [],
"aliases": [
"CVE-2024-53207"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible deadlocks\n\nThis fixes possible deadlocks like the following caused by\nhci_cmd_sync_dequeue causing the destroy function to run:\n\n INFO: task kworker/u19:0:143 blocked for more than 120 seconds.\n Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000\n Workqueue: hci0 hci_cmd_sync_work [bluetooth]\n Call Trace:\n \u003cTASK\u003e\n __schedule+0x374/0xaf0\n schedule+0x3c/0xf0\n schedule_preempt_disabled+0x1c/0x30\n __mutex_lock.constprop.0+0x3ef/0x7a0\n __mutex_lock_slowpath+0x13/0x20\n mutex_lock+0x3c/0x50\n mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]\n ? kfree+0x211/0x2a0\n hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]\n ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]\n cmd_complete_rsp+0x26/0x80 [bluetooth]\n mgmt_pending_foreach+0x4d/0x70 [bluetooth]\n __mgmt_power_off+0x8d/0x180 [bluetooth]\n ? _raw_spin_unlock_irq+0x23/0x40\n hci_dev_close_sync+0x445/0x5b0 [bluetooth]\n hci_set_powered_sync+0x149/0x250 [bluetooth]\n set_powered_sync+0x24/0x60 [bluetooth]\n hci_cmd_sync_work+0x90/0x150 [bluetooth]\n process_one_work+0x13e/0x300\n worker_thread+0x2f7/0x420\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x107/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x3d/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e",
"id": "GHSA-fgfp-pp34-jxvv",
"modified": "2025-11-03T21:31:49Z",
"published": "2024-12-27T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5703fb1d85f653e35b327b14de4db7da239e4fd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a25ce9b4af6dc26ee2b9c32d6bd37620bf9739e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a66dfaf18fd61bb75ef8cee83db46b2aadf153d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3f594a3473d6429a0bcf2004cb2885368741b79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cac34e44281f1f1bd842adbbcfe3ef9ff0905111"
},
{
"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-FGJ9-8C8V-JFWQ
Vulnerability from github – Published: 2022-04-30 18:18 – Updated: 2024-02-08 21:30Windows 2000 allows local users to prevent the application of new group policy settings by opening Group Policy files with exclusive-read access.
{
"affected": [],
"aliases": [
"CVE-2002-0051"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-04-04T05:00:00Z",
"severity": "MODERATE"
},
"details": "Windows 2000 allows local users to prevent the application of new group policy settings by opening Group Policy files with exclusive-read access.",
"id": "GHSA-fgj9-8c8v-jfwq",
"modified": "2024-02-08T21:30:29Z",
"published": "2022-04-30T18:18:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-0051"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2002/ms02-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A38"
},
{
"type": "WEB",
"url": "http://online.securityfocus.com/archive/1/244329"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/4438"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FH88-V2MJ-CP79
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
erofs: handle overlapped pclusters out of crafted images properly
syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os.
After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below:
Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ...
Here, extent 0/1 are physically overlapped although it's entirely impossible for normal filesystem images generated by mkfs.
First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits.
Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness.
Additionally, it justifies that referenced managed folios cannot be
truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy
up struct z_erofs_bvec") for simplicity although it shouldn't be any
difference.
{
"affected": [],
"aliases": [
"CVE-2024-47736"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it\u0027s formed with\nseveral overlapped big pclusters as below:\n\n Ext: logical offset | length : physical offset | length\n 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384\n 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384\n 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384\n...\n\nHere, extent 0/1 are physically overlapped although it\u0027s entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete. If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues. However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries. However, this is somewhat hard to implement\neasily if overlapped big pclusters exist. Again, these only appear in\nfuzzed images so let\u0027s simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn\u0027t be any\ndifference.",
"id": "GHSA-fh88-v2mj-cp79",
"modified": "2026-07-14T15:31:15Z",
"published": "2024-10-21T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47736"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1172e65aad4b115392ea4c6e61e56e5b9b69df4"
}
],
"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-FHMX-7JHG-8H34
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:
task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963
with the attempting freezer stuck trying to grab the rwsem:
task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170
Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.
Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.
{
"affected": [],
"aliases": [
"CVE-2024-53052"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rw: fix missing NOWAIT check for O_DIRECT start write\n\nWhen io_uring starts a write, it\u0027ll call kiocb_start_write() to bump the\nsuper block rwsem, preventing any freezes from happening while that\nwrite is in-flight. The freeze side will grab that rwsem for writing,\nexcluding any new writers from happening and waiting for existing writes\nto finish. But io_uring unconditionally uses kiocb_start_write(), which\nwill block if someone is currently attempting to freeze the mount point.\nThis causes a deadlock where freeze is waiting for previous writes to\ncomplete, but the previous writes cannot complete, as the task that is\nsupposed to complete them is blocked waiting on starting a new write.\nThis results in the following stuck trace showing that dependency with\nthe write blocked starting a new write:\n\ntask:fio state:D stack:0 pid:886 tgid:886 ppid:876\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_rwsem_wait+0x1e8/0x3f8\n __percpu_down_read+0xe8/0x500\n io_write+0xbb8/0xff8\n io_issue_sqe+0x10c/0x1020\n io_submit_sqes+0x614/0x2110\n __arm64_sys_io_uring_enter+0x524/0x1038\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\nINFO: task fsfreeze:7364 blocked for more than 15 seconds.\n Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963\n\nwith the attempting freezer stuck trying to grab the rwsem:\n\ntask:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_down_write+0x2b0/0x680\n freeze_super+0x248/0x8a8\n do_vfs_ioctl+0x149c/0x1b18\n __arm64_sys_ioctl+0xd0/0x1a0\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\n\nFix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a\nblocking grab of the super block rwsem if it isn\u0027t set. For normal issue\nwhere IOCB_NOWAIT would always be set, this returns -EAGAIN which will\nhave io_uring core issue a blocking attempt of the write. That will in\nturn also get completions run, ensuring forward progress.\n\nSince freezing requires CAP_SYS_ADMIN in the first place, this isn\u0027t\nsomething that can be triggered by a regular user.",
"id": "GHSA-fhmx-7jhg-8h34",
"modified": "2025-11-04T00:32:04Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/003d2996964c03dfd34860500428f4cdf1f5879e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/485d9232112b17f389b29497ff41b97b3189546b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e24041ba86d50aaa4c792ae2c88ed01b3d96243"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e8debb8e51354b201db494689198078ec2c1e75"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FP9W-CXGG-VH4H
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-08 06:30In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-42775"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.",
"id": "GHSA-fp9w-cxgg-vh4h",
"modified": "2022-12-08T06:30:30Z",
"published": "2022-12-06T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42775"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
}
],
"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-FQ5H-CM7Q-5GG6
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix deadlock in ni_read_folio_cmpr
Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock involving the inode mutex (ni_lock) and page locks.
Scenario: 1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock. 2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in the compressed frame (including page Y). 3. Concurrently, Task B (e.g., via readahead) has locked page Y and calls ntfs_read_folio(). 4. Task B waits for ni_lock (held by A). 5. Task A waits for page Y lock (held by B). -> DEADLOCK.
The fix is to restructure locking: do not take ni_lock in ntfs_read_folio(). Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required page locks for the frame have been successfully acquired. This restores the correct lock ordering (Page Lock -> ni_lock) consistent with VFS.
[almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]
{
"affected": [],
"aliases": [
"CVE-2025-71309"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:16:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: fix deadlock in ni_read_folio_cmpr\n\nSyzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr).\nThis is caused by a lock inversion deadlock involving the inode mutex\n(ni_lock) and page locks.\n\nScenario:\n1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock.\n2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in\n the compressed frame (including page Y).\n3. Concurrently, Task B (e.g., via readahead) has locked page Y and\n calls ntfs_read_folio().\n4. Task B waits for ni_lock (held by A).\n5. Task A waits for page Y lock (held by B).\n -\u003e DEADLOCK.\n\nThe fix is to restructure locking: do not take ni_lock in ntfs_read_folio().\nInstead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required\npage locks for the frame have been successfully acquired. This restores the\ncorrect lock ordering (Page Lock -\u003e ni_lock) consistent with VFS.\n\n[almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]",
"id": "GHSA-fq5h-cm7q-5gg6",
"modified": "2026-06-25T21:31:18Z",
"published": "2026-05-27T15:33:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71309"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfe246b318106e1691bd6c9466c739e8559d25c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e37a75bb866c29da954b51d0dd7670406246d9ee"
}
],
"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-FQHG-58RX-5GHM
Vulnerability from github – Published: 2022-05-26 00:01 – Updated: 2024-05-03 00:30MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (i.e., going to the err label) while executing the method create_worker_threads, the held lock thd->ctrl_mutex is not released correctly, which allows local users to trigger a denial of service due to the deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-31623"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-25T21:15:00Z",
"severity": "MODERATE"
},
"details": "MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (i.e., going to the err label) while executing the method create_worker_threads, the held lock thd-\u003ectrl_mutex is not released correctly, which allows local users to trigger a denial of service due to the deadlock.",
"id": "GHSA-fqhg-58rx-5ghm",
"modified": "2024-05-03T00:30:43Z",
"published": "2022-05-26T00:01:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31623"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/pull/1938"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/commit/7c30bc38a588b22b01f11130cfe99e7f36accf94"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26561"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26574"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220707-0006"
}
],
"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-FQPV-6GRR-R8M7
Vulnerability from github – Published: 2022-04-08 00:00 – Updated: 2022-04-16 00:01A Denial of Service vulnerability exists in CORTX-S3 Server as of 11/7/2021 via the mempool_destroy method due to a failture to release locks pool->lock.
{
"affected": [],
"aliases": [
"CVE-2021-43429"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-07T17:15:00Z",
"severity": "HIGH"
},
"details": "A Denial of Service vulnerability exists in CORTX-S3 Server as of 11/7/2021 via the mempool_destroy method due to a failture to release locks pool-\u003elock.",
"id": "GHSA-fqpv-6grr-r8m7",
"modified": "2022-04-16T00:01:30Z",
"published": "2022-04-08T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43429"
},
{
"type": "WEB",
"url": "https://github.com/Seagate/cortx-s3server/issues/1037"
},
{
"type": "WEB",
"url": "https://github.com/Seagate/cortx-s3server/pull/1041"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FV7F-R8H4-5HH2
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.
{
"affected": [],
"aliases": [
"CVE-2025-38094"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T08:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cadence: macb: Fix a possible deadlock in macb_halt_tx.\n\nThere is a situation where after THALT is set high, TGO stays high as\nwell. Because jiffies are never updated, as we are in a context with\ninterrupts disabled, we never exit that loop and have a deadlock.\n\nThat deadlock was noticed on a sama5d4 device that stayed locked for days.\n\nUse retries instead of jiffies so that the timeout really works and we do\nnot have a deadlock anymore.",
"id": "GHSA-fv7f-r8h4-5hh2",
"modified": "2025-12-16T18:31:28Z",
"published": "2025-07-03T09:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38094"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.