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.
724 vulnerabilities reference this CWE, most recent first.
GHSA-59HF-6V72-VM3M
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-09-24 18:30In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below:
ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork
The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens.
Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock.
Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.
{
"affected": [],
"aliases": [
"CVE-2024-35971"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Handle softirqs at the end of IRQ thread to fix hang\n\nThe ks8851_irq() thread may call ks8851_rx_pkts() in case there are\nany packets in the MAC FIFO, which calls netif_rx(). This netif_rx()\nimplementation is guarded by local_bh_disable() and local_bh_enable().\nThe local_bh_enable() may call do_softirq() to run softirqs in case\nany are pending. One of the softirqs is net_rx_action, which ultimately\nreaches the driver .start_xmit callback. If that happens, the system\nhangs. The entire call chain is below:\n\nks8851_start_xmit_par from netdev_start_xmit\nnetdev_start_xmit from dev_hard_start_xmit\ndev_hard_start_xmit from sch_direct_xmit\nsch_direct_xmit from __dev_queue_xmit\n__dev_queue_xmit from __neigh_update\n__neigh_update from neigh_update\nneigh_update from arp_process.constprop.0\narp_process.constprop.0 from __netif_receive_skb_one_core\n__netif_receive_skb_one_core from process_backlog\nprocess_backlog from __napi_poll.constprop.0\n__napi_poll.constprop.0 from net_rx_action\nnet_rx_action from __do_softirq\n__do_softirq from call_with_stack\ncall_with_stack from do_softirq\ndo_softirq from __local_bh_enable_ip\n__local_bh_enable_ip from netif_rx\nnetif_rx from ks8851_irq\nks8851_irq from irq_thread_fn\nirq_thread_fn from irq_thread\nirq_thread from kthread\nkthread from ret_from_fork\n\nThe hang happens because ks8851_irq() first locks a spinlock in\nks8851_par.c ks8851_lock_par() spin_lock_irqsave(\u0026ksp-\u003elock, ...)\nand with that spinlock locked, calls netif_rx(). Once the execution\nreaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again\nwhich attempts to claim the already locked spinlock again, and the\nhang happens.\n\nMove the do_softirq() call outside of the spinlock protected section\nof ks8851_irq() by disabling BHs around the entire spinlock protected\nsection of ks8851_irq() handler. Place local_bh_enable() outside of\nthe spinlock protected section, so that it can trigger do_softirq()\nwithout the ks8851_par.c ks8851_lock_par() spinlock being held, and\nsafely call ks8851_start_xmit_par() without attempting to lock the\nalready locked spinlock.\n\nSince ks8851_irq() is protected by local_bh_disable()/local_bh_enable()\nnow, replace netif_rx() with __netif_rx() which is not duplicating the\nlocal_bh_disable()/local_bh_enable() calls.",
"id": "GHSA-59hf-6v72-vm3m",
"modified": "2025-09-24T18:30:22Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35971"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/2"
}
],
"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-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"
}
]
}
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.