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-5C36-JX4M-M84F
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-13 21:31In the Linux kernel, the following vulnerability has been resolved:
Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"
This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands:
$ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove
A trimmed trace of the deadlock on a mlx5 device is as below:
zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140
but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90
This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.
{
"affected": [],
"aliases": [
"CVE-2026-43147"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"\n\nThis reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking\nwhen enabling/disabling SR-IOV\"), which causes a deadlock by recursively\ntaking pci_rescan_remove_lock when sriov_del_vfs() is called as part of\npci_stop_and_remove_bus_device(). For example with the following sequence\nof commands:\n\n $ echo \u003cNUM\u003e \u003e /sys/bus/pci/devices/\u003cpf\u003e/sriov_numvfs\n $ echo 1 \u003e /sys/bus/pci/devices/\u003cpf\u003e/remove\n\nA trimmed trace of the deadlock on a mlx5 device is as below:\n\n zsh/5715 is trying to acquire lock:\n 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140\n\n but task is already holding lock:\n 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80\n ...\n Call Trace:\n [\u003c00000259778c4f90\u003e] dump_stack_lvl+0xc0/0x110\n [\u003c00000259779c844e\u003e] print_deadlock_bug+0x31e/0x330\n [\u003c00000259779c1908\u003e] __lock_acquire+0x16c8/0x32f0\n [\u003c00000259779bffac\u003e] lock_acquire+0x14c/0x350\n [\u003c00000259789643a6\u003e] __mutex_lock_common+0xe6/0x1520\n [\u003c000002597896413c\u003e] mutex_lock_nested+0x3c/0x50\n [\u003c00000259784a07e4\u003e] sriov_disable+0x34/0x140\n [\u003c00000258f7d6dd80\u003e] mlx5_sriov_disable+0x50/0x80 [mlx5_core]\n [\u003c00000258f7d5745e\u003e] remove_one+0x5e/0xf0 [mlx5_core]\n [\u003c00000259784857fc\u003e] pci_device_remove+0x3c/0xa0\n [\u003c000002597851012e\u003e] device_release_driver_internal+0x18e/0x280\n [\u003c000002597847ae22\u003e] pci_stop_bus_device+0x82/0xa0\n [\u003c000002597847afce\u003e] pci_stop_and_remove_bus_device_locked+0x5e/0x80\n [\u003c00000259784972c2\u003e] remove_store+0x72/0x90\n [\u003c0000025977e6661a\u003e] kernfs_fop_write_iter+0x15a/0x200\n [\u003c0000025977d7241c\u003e] vfs_write+0x24c/0x300\n [\u003c0000025977d72696\u003e] ksys_write+0x86/0x110\n [\u003c000002597895b61c\u003e] __do_syscall+0x14c/0x400\n [\u003c000002597896e0ee\u003e] system_call+0x6e/0x90\n\nThis alone is not a complete fix as it restores the issue the cited commit\ntried to solve. A new fix will be provided as a follow on.",
"id": "GHSA-5c36-jx4m-m84f",
"modified": "2026-05-13T21:31:58Z",
"published": "2026-05-06T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43147"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0de341b2365bad430aade0853fe09c2cbe468f59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f67686a5002c0c322fac918406bbc8d9c2ec2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58677783c89681871077f50a7042b0c6380c4fd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/639265296fe6ee21b6f00e00ee2bab65f3b07252"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83651d37474c762920e345a3a0828f975ca4d732"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d47f27e145f8bd13f3c230da5e3af29225b4a2f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f61cdd7e9b67bb8961b0a81bf294b78343e5db05"
}
],
"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-5FJR-C5P8-HXVJ
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10btrfs in the Linux kernel before 5.13.4 allows attackers to cause a denial of service (deadlock) via processes that trigger allocation of new system chunks during times when there is a shortage of free space in the system space_info.
{
"affected": [],
"aliases": [
"CVE-2021-38203"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-08T20:15:00Z",
"severity": "MODERATE"
},
"details": "btrfs in the Linux kernel before 5.13.4 allows attackers to cause a denial of service (deadlock) via processes that trigger allocation of new system chunks during times when there is a shortage of free space in the system space_info.",
"id": "GHSA-5fjr-c5p8-hxvj",
"modified": "2022-05-24T19:10:23Z",
"published": "2022-05-24T19:10:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38203"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/1cb3db1cf383a3c7dbda1aa0ce748b0958759947"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.4"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210902-0010"
}
],
"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-5FXQ-3R3P-42M4
Vulnerability from github – Published: 2022-04-30 18:13 – Updated: 2024-02-08 21:30Concurrent Versions Software (CVS) uses predictable temporary file names for locking, which allows local users to cause a denial of service by creating the lock directory before it is created for use by a legitimate CVS user.
{
"affected": [],
"aliases": [
"CVE-2000-0338"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2000-04-23T04:00:00Z",
"severity": "MODERATE"
},
"details": "Concurrent Versions Software (CVS) uses predictable temporary file names for locking, which allows local users to cause a denial of service by creating the lock directory before it is created for use by a legitimate CVS user.",
"id": "GHSA-5fxq-3r3p-42m4",
"modified": "2024-02-08T21:30:28Z",
"published": "2022-04-30T18:13:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2000-0338"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/1136"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26msg%3D20000423174038.A520%40clico.pl"
}
],
"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-5GR3-HCQ9-FP58
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05In memory management driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185195268
{
"affected": [],
"aliases": [
"CVE-2021-0529"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-21T17:15:00Z",
"severity": "HIGH"
},
"details": "In memory management driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185195268",
"id": "GHSA-5gr3-hcq9-fp58",
"modified": "2022-05-24T19:05:42Z",
"published": "2022-05-24T19:05:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0529"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2021-06-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5H69-GPMH-V98W
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
x86/shstk: Prevent deadlock during shstk sigreturn
During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA.
Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock.
Fix this by not holding mmap lock during the read access to userspace.
Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA.
These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist.
Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.
{
"affected": [],
"aliases": [
"CVE-2026-46063"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/shstk: Prevent deadlock during shstk sigreturn\n\nDuring sigreturn the shadow stack signal frame is popped. The kernel does\nthis by reading the shadow stack using normal read accesses. When it can\u0027t\nassume the memory is shadow stack, it takes extra steps to makes sure it is\nreading actual shadow stack memory and not other normal readable memory. It\ndoes this by holding the mmap read lock while doing the access and checking\nthe flags of the VMA.\n\nUnfortunately that is not safe. If the read of the shadow stack sigframe\nhits a page fault, the fault handler will try to recursively grab another\nmmap read lock. This normally works ok, but if a writer on another CPU is\nalso waiting, the second read lock could fail and cause a deadlock.\n\nFix this by not holding mmap lock during the read access to userspace.\n\nInstead use mmap_lock_speculate_...() to watch for changes between dropping\nmmap lock and the userspace access. Retry if anything grabbed an mmap write\nlock in between and could have changed the VMA.\n\nThese mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only\navailable when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK\ndepend on it. On x86, PER_VMA_LOCK is a default configuration for SMP\nkernels. So drop support for the other configs under the assumption that\nthe !SMP shadow stack user base does not exist.\n\nCurrently there is a check that skips the lookup work when the SSP can be\nassumed to be on a shadow stack. While reorganizing the function, remove\nthe optimization to make the tricky code flows more common, such that\nissues like this cannot escape detection for so long.",
"id": "GHSA-5h69-gpmh-v98w",
"modified": "2026-06-16T03:30:34Z",
"published": "2026-05-27T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46063"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d29db827502067626062f5c74dd502d14ab15bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f3374c990fb2adec06d20fd6d780927811c9aa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9874b2917b9fbc30956fee209d3c4aa47201c64e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d042d69b417515959e49021fef008c9b04a99bd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2c2b044458cbf22da05264fa707308e8d4f86f9"
}
],
"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-5HMX-W727-FQQ7
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-11-05 00:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix lockup on kernel exec fault
The powerpc kernel is not prepared to handle exec faults from kernel. Especially, the function is_exec_fault() will return 'false' when an exec fault is taken by kernel, because the check is based on reading current->thread.regs->trap which contains the trap from user.
For instance, when provoking a LKDTM EXEC_USERSPACE test, current->thread.regs->trap is set to SYSCALL trap (0xc00), and the fault taken by the kernel is not seen as an exec fault by set_access_flags_filter().
Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix with autonuma") made it clear and handled it properly. But later on commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") removed that handling, introducing test based on error_code. And here is the problem, because on the 603 all upper bits of SRR1 get cleared when the TLB instruction miss handler bails out to ISI.
Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy search_exception_tables() verification"), an exec fault from kernel at a userspace address was indirectly caught by the lack of entry for that address in the exception tables. But after that commit the kernel mainly relies on KUAP or on core mm handling to catch wrong user accesses. Here the access is not wrong, so mm handles it. It is a minor fault because PAGE_EXEC is not set, set_access_flags_filter() should set PAGE_EXEC and voila. But as is_exec_fault() returns false as explained in the beginning, set_access_flags_filter() bails out without setting PAGE_EXEC flag, which leads to a forever minor exec fault.
As the kernel is not prepared to handle such exec faults, the thing to do is to fire in bad_kernel_fault() for any exec fault taken by the kernel, as it was prior to commit d3ca587404b3.
{
"affected": [],
"aliases": [
"CVE-2021-47350"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm: Fix lockup on kernel exec fault\n\nThe powerpc kernel is not prepared to handle exec faults from kernel.\nEspecially, the function is_exec_fault() will return \u0027false\u0027 when an\nexec fault is taken by kernel, because the check is based on reading\ncurrent-\u003ethread.regs-\u003etrap which contains the trap from user.\n\nFor instance, when provoking a LKDTM EXEC_USERSPACE test,\ncurrent-\u003ethread.regs-\u003etrap is set to SYSCALL trap (0xc00), and\nthe fault taken by the kernel is not seen as an exec fault by\nset_access_flags_filter().\n\nCommit d7df2443cd5f (\"powerpc/mm: Fix spurious segfaults on radix\nwith autonuma\") made it clear and handled it properly. But later on\ncommit d3ca587404b3 (\"powerpc/mm: Fix reporting of kernel execute\nfaults\") removed that handling, introducing test based on error_code.\nAnd here is the problem, because on the 603 all upper bits of SRR1\nget cleared when the TLB instruction miss handler bails out to ISI.\n\nUntil commit cbd7e6ca0210 (\"powerpc/fault: Avoid heavy\nsearch_exception_tables() verification\"), an exec fault from kernel\nat a userspace address was indirectly caught by the lack of entry for\nthat address in the exception tables. But after that commit the\nkernel mainly relies on KUAP or on core mm handling to catch wrong\nuser accesses. Here the access is not wrong, so mm handles it.\nIt is a minor fault because PAGE_EXEC is not set,\nset_access_flags_filter() should set PAGE_EXEC and voila.\nBut as is_exec_fault() returns false as explained in the beginning,\nset_access_flags_filter() bails out without setting PAGE_EXEC flag,\nwhich leads to a forever minor exec fault.\n\nAs the kernel is not prepared to handle such exec faults, the thing to\ndo is to fire in bad_kernel_fault() for any exec fault taken by the\nkernel, as it was prior to commit d3ca587404b3.",
"id": "GHSA-5hmx-w727-fqq7",
"modified": "2024-11-05T00:31:27Z",
"published": "2024-05-21T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47350"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/500f81cec9f1bfa5210aa9dd5ba9a06e22f62a35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a96ec5ebf96ad8e2ba7b1b34103a0be5140fc70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a82471a14aad90f79d1608d2bcbb019f0ffb53f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd5d5e602f502895e47e18cd46804d6d7014e65c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2e52d4664097a6c1f591d869ec594bd7a0d4925"
}
],
"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-5J77-G9MW-C64C
Vulnerability from github – Published: 2023-03-24 21:30 – Updated: 2023-03-29 15:30In MediaCodec.cpp, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-194783918
{
"affected": [],
"aliases": [
"CVE-2023-21000"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-24T20:15:00Z",
"severity": "HIGH"
},
"details": "In MediaCodec.cpp, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-194783918",
"id": "GHSA-5j77-g9mw-c64c",
"modified": "2023-03-29T15:30:16Z",
"published": "2023-03-24T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21000"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-03-01"
}
],
"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-5MWV-X2QC-G5CJ
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2024-11-06 18:31In the Linux kernel, the following vulnerability has been resolved:
nvme: fix reconnection fail due to reserved tag allocation
We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
{
"affected": [],
"aliases": [
"CVE-2024-27435"
],
"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\nnvme: fix reconnection fail due to reserved tag allocation\n\nWe found a issue on production environment while using NVMe over RDMA,\nadmin_q reconnect failed forever while remote target and network is ok.\nAfter dig into it, we found it may caused by a ABBA deadlock due to tag\nallocation. In my case, the tag was hold by a keep alive request\nwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so the\nrequest maked as idle and will not process before reset success. As\nfabric_q shares tagset with admin_q, while reconnect remote target, we\nneed a tag for connect command, but the only one reserved tag was held\nby keep alive command which waiting inside admin_q. As a result, we\nfailed to reconnect admin_q forever. In order to fix this issue, I\nthink we should keep two reserved tags for admin queue.",
"id": "GHSA-5mwv-x2qc-g5cj",
"modified": "2024-11-06T18:31:04Z",
"published": "2024-05-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27435"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a"
}
],
"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-5P3M-PW6J-5JWM
Vulnerability from github – Published: 2024-02-26 18:30 – Updated: 2024-04-28 12:30In the Linux kernel, the following vulnerability has been resolved:
PCI/ASPM: Fix deadlock when enabling ASPM
A last minute revert in 6.7-final introduced a potential deadlock when enabling ASPM during probe of Qualcomm PCIe controllers as reported by lockdep:
============================================ WARNING: possible recursive locking detected 6.7.0 #40 Not tainted
kworker/u16:5/90 is trying to acquire lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc
but task is already holding lock:
ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(pci_bus_sem);
lock(pci_bus_sem);
*** DEADLOCK ***
Call trace: print_deadlock_bug+0x25c/0x348 __lock_acquire+0x10a4/0x2064 lock_acquire+0x1e8/0x318 down_read+0x60/0x184 pcie_aspm_pm_state_change+0x58/0xdc pci_set_full_power_state+0xa8/0x114 pci_set_power_state+0xc4/0x120 qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom] pci_walk_bus+0x64/0xbc qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]
The deadlock can easily be reproduced on machines like the Lenovo ThinkPad X13s by adding a delay to increase the race window during asynchronous probe where another thread can take a write lock.
Add a new pci_set_power_state_locked() and associated helper functions that can be called with the PCI bus semaphore held to avoid taking the read lock twice.
{
"affected": [],
"aliases": [
"CVE-2024-26605"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-26T16:28:00Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/ASPM: Fix deadlock when enabling ASPM\n\nA last minute revert in 6.7-final introduced a potential deadlock when\nenabling ASPM during probe of Qualcomm PCIe controllers as reported by\nlockdep:\n\n ============================================\n WARNING: possible recursive locking detected\n 6.7.0 #40 Not tainted\n --------------------------------------------\n kworker/u16:5/90 is trying to acquire lock:\n ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc\n\n but task is already holding lock:\n ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(pci_bus_sem);\n lock(pci_bus_sem);\n\n *** DEADLOCK ***\n\n Call trace:\n print_deadlock_bug+0x25c/0x348\n __lock_acquire+0x10a4/0x2064\n lock_acquire+0x1e8/0x318\n down_read+0x60/0x184\n pcie_aspm_pm_state_change+0x58/0xdc\n pci_set_full_power_state+0xa8/0x114\n pci_set_power_state+0xc4/0x120\n qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]\n pci_walk_bus+0x64/0xbc\n qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]\n\nThe deadlock can easily be reproduced on machines like the Lenovo ThinkPad\nX13s by adding a delay to increase the race window during asynchronous\nprobe where another thread can take a write lock.\n\nAdd a new pci_set_power_state_locked() and associated helper functions that\ncan be called with the PCI bus semaphore held to avoid taking the read lock\ntwice.",
"id": "GHSA-5p3m-pw6j-5jwm",
"modified": "2024-04-28T12:30:27Z",
"published": "2024-02-26T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26605"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f7908a016c092cfdaa16d785fa5099d867bc1a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e560864159d002b453da42bd2c13a1805515a20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0f4478838be1f1d330061201898fef65bf8fd7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef90508574d7af48420bdc5f7b9a4f1cdd26bc70"
}
],
"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-5PX9-QGXF-P79C
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix a deadlock when recovering state on a sillyrenamed file
If the file is sillyrenamed, and slated for delete on close, it is possible for a server reboot to triggeer an open reclaim, with can again race with the application call to close(). When that happens, the call to put_nfs_open_context() can trigger a synchronous delegreturn call which deadlocks because it is not marked as privileged.
Instead, ensure that the call to nfs4_inode_return_delegation_on_close() catches the delegreturn, and schedules it asynchronously.
{
"affected": [],
"aliases": [
"CVE-2025-21900"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Fix a deadlock when recovering state on a sillyrenamed file\n\nIf the file is sillyrenamed, and slated for delete on close, it is\npossible for a server reboot to triggeer an open reclaim, with can again\nrace with the application call to close(). When that happens, the call\nto put_nfs_open_context() can trigger a synchronous delegreturn call\nwhich deadlocks because it is not marked as privileged.\n\nInstead, ensure that the call to nfs4_inode_return_delegation_on_close()\ncatches the delegreturn, and schedules it asynchronously.",
"id": "GHSA-5px9-qgxf-p79c",
"modified": "2025-04-15T18:31:42Z",
"published": "2025-04-01T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21900"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4fe4ae6c2e01d028856b73b6328b12b8945df871"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f8df955f078e1a023ee55161935000a67651f38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f41a60bc43e7abbc636fee78bed0d74c31e738b0"
}
],
"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.