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.
721 vulnerabilities reference this CWE, most recent first.
GHSA-MC7V-WPQV-V4G2
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2024-11-06 18:31In the Linux kernel, the following vulnerability has been resolved:
Input: cyapa - add missing input core locking to suspend/resume functions
Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]---
{
"affected": [],
"aliases": [
"CVE-2023-52884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: cyapa - add missing input core locking to suspend/resume functions\n\nGrab input-\u003emutex during suspend/resume functions like it is done in\nother input drivers. This fixes the following warning during system\nsuspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---\n...\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---",
"id": "GHSA-mc7v-wpqv-v4g2",
"modified": "2024-11-06T18:31:05Z",
"published": "2024-06-21T12:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75"
}
],
"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-MF7M-5PJ7-586W
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In startLockTaskMode of LockTaskController.java, there is a possible bypass of lock task mode due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-213942596
{
"affected": [],
"aliases": [
"CVE-2023-21189"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:15Z",
"severity": "HIGH"
},
"details": "In startLockTaskMode of LockTaskController.java, there is a possible bypass of lock task mode due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-213942596",
"id": "GHSA-mf7m-5pj7-586w",
"modified": "2024-04-04T05:15:25Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21189"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MFFP-559Q-RCHQ
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-03-05 15:30In the Linux kernel, the following vulnerability has been resolved:
rhashtable: Fix potential deadlock by moving schedule_work outside lock
Move the hash table growth check and work scheduling outside the rht lock to prevent a possible circular locking dependency.
The original implementation could trigger a lockdep warning due to a potential deadlock scenario involving nested locks between rhashtable bucket, rq lock, and dsq lock. By relocating the growth check and work scheduling after releasing the rth lock, we break this potential deadlock chain.
This change expands the flexibility of rhashtable by removing restrictive locking that previously limited its use in scheduler and workqueue contexts.
Import to say that this calls rht_grow_above_75(), which reads from struct rhashtable without holding the lock, if this is a problem, we can move the check to the lock, and schedule the workqueue after the lock.
Modified so that atomic_inc is also moved outside of the bucket lock along with the growth above 75% check.
{
"affected": [],
"aliases": [
"CVE-2024-58042"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrhashtable: Fix potential deadlock by moving schedule_work outside lock\n\nMove the hash table growth check and work scheduling outside the\nrht lock to prevent a possible circular locking dependency.\n\nThe original implementation could trigger a lockdep warning due to\na potential deadlock scenario involving nested locks between\nrhashtable bucket, rq lock, and dsq lock. By relocating the\ngrowth check and work scheduling after releasing the rth lock, we break\nthis potential deadlock chain.\n\nThis change expands the flexibility of rhashtable by removing\nrestrictive locking that previously limited its use in scheduler\nand workqueue contexts.\n\nImport to say that this calls rht_grow_above_75(), which reads from\nstruct rhashtable without holding the lock, if this is a problem, we can\nmove the check to the lock, and schedule the workqueue after the lock.\n\n\nModified so that atomic_inc is also moved outside of the bucket\nlock along with the growth above 75% check.",
"id": "GHSA-mffp-559q-rchq",
"modified": "2025-03-05T15:30:51Z",
"published": "2025-02-27T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58042"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ced8ce3c83a7150c5f5d371a8c332d7bc7f9b66d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1d3422c95f003eba241c176adfe593c33e8a8f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb2e58484b838fb4e777ee9721bb9e20e6ca971d"
}
],
"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-MFR6-F95C-8CHR
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22An issue was discovered in ShopXO 1.2.0. In the application\install\controller\Index.php file, there is no validation lock file in the Add method, which allows an attacker to reinstall the database. The attacker can write arbitrary code to database.php during system reinstallation.
{
"affected": [],
"aliases": [
"CVE-2019-5886"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-10T14:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in ShopXO 1.2.0. In the application\\install\\controller\\Index.php file, there is no validation lock file in the Add method, which allows an attacker to reinstall the database. The attacker can write arbitrary code to database.php during system reinstallation.",
"id": "GHSA-mfr6-f95c-8chr",
"modified": "2022-05-13T01:22:33Z",
"published": "2022-05-13T01:22:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5886"
},
{
"type": "WEB",
"url": "https://github.com/gongfuxiang/shopxo/issues/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MFVR-QGFC-WVXQ
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-12 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/xe/userptr: fix notifier vs folio deadlock
User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock.
Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it.
(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)
{
"affected": [],
"aliases": [
"CVE-2025-37868"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/userptr: fix notifier vs folio deadlock\n\nUser is reporting what smells like notifier vs folio deadlock, where\nmigrate_pages_batch() on core kernel side is holding folio lock(s) and\nthen interacting with the mappings of it, however those mappings are\ntied to some userptr, which means calling into the notifier callback and\ngrabbing the notifier lock. With perfect timing it looks possible that\nthe pages we pulled from the hmm fault can get sniped by\nmigrate_pages_batch() at the same time that we are holding the notifier\nlock to mark the pages as accessed/dirty, but at this point we also want\nto grab the folio locks(s) to mark them as dirty, but if they are\ncontended from notifier/migrate_pages_batch side then we deadlock since\nfolio lock won\u0027t be dropped until we drop the notifier lock.\n\nFortunately the mark_page_accessed/dirty is not really needed in the\nfirst place it seems and should have already been done by hmm fault, so\njust remove it.\n\n(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)",
"id": "GHSA-mfvr-qgfc-wvxq",
"modified": "2025-11-12T21:31:02Z",
"published": "2025-05-09T09:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2577b202458cddff85cc154b1fe7f313e0d1f418"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90574ecf6052be83971d91d16600c5cf07003bbb"
}
],
"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-MG38-475C-J5R2
Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2022-05-13 01:17A vulnerability in the ingress flow creation functionality of Cisco Adaptive Security Appliance (ASA) could allow an unauthenticated, remote attacker to cause the CPU to increase upwards of 100% utilization, causing a denial of service (DoS) condition on an affected system. The vulnerability is due to incorrect handling of an internal software lock that could prevent other system processes from getting CPU cycles, causing a high CPU condition. An attacker could exploit this vulnerability by sending a steady stream of malicious IP packets that can cause connections to be created on the targeted device. A successful exploit could allow the attacker to exhaust CPU resources, resulting in a DoS condition during which traffic through the device could be delayed. This vulnerability applies to either IPv4 or IPv6 ingress traffic. This vulnerability affects Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) Software that is running on the following Cisco products: 3000 Series Industrial Security Appliances (ISA), ASA 5500 Series Adaptive Security Appliances, ASA 5500-X Series Next-Generation Firewalls, ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers, Adaptive Security Virtual Appliances (ASAv), Firepower 2100 Series Security Appliances, Firepower 4110 Security Appliances, Firepower 9300 ASA Security Modules. Cisco Bug IDs: CSCvf63718.
{
"affected": [],
"aliases": [
"CVE-2018-0228"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-19T20:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the ingress flow creation functionality of Cisco Adaptive Security Appliance (ASA) could allow an unauthenticated, remote attacker to cause the CPU to increase upwards of 100% utilization, causing a denial of service (DoS) condition on an affected system. The vulnerability is due to incorrect handling of an internal software lock that could prevent other system processes from getting CPU cycles, causing a high CPU condition. An attacker could exploit this vulnerability by sending a steady stream of malicious IP packets that can cause connections to be created on the targeted device. A successful exploit could allow the attacker to exhaust CPU resources, resulting in a DoS condition during which traffic through the device could be delayed. This vulnerability applies to either IPv4 or IPv6 ingress traffic. This vulnerability affects Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) Software that is running on the following Cisco products: 3000 Series Industrial Security Appliances (ISA), ASA 5500 Series Adaptive Security Appliances, ASA 5500-X Series Next-Generation Firewalls, ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers, Adaptive Security Virtual Appliances (ASAv), Firepower 2100 Series Security Appliances, Firepower 4110 Security Appliances, Firepower 9300 ASA Security Modules. Cisco Bug IDs: CSCvf63718.",
"id": "GHSA-mg38-475c-j5r2",
"modified": "2022-05-13T01:17:27Z",
"published": "2022-05-13T01:17:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0228"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-184-01"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-asa2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104220"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040724"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MG8G-G7C5-2WPM
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-20 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work
A state check was previously added to tcpm_queue_vdm_unlocked to prevent a deadlock where the DisplayPort Alt Mode driver would be executing work and attempting to grab the tcpm_lock while the TCPM was holding the lock and attempting to unregister the altmode, blocking on the altmode driver's cancel_work_sync call.
Because the state check isn't protected, there is a small window where the Alt Mode driver could determine that the TCPM is in a ready state and attempt to grab the lock while the TCPM grabs the lock and changes the TCPM state to one that causes the deadlock. The callstack is provided below:
[110121.667392][ C7] Call trace: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20
[110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20
Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, which can perform the state check while holding the TCPM lock while the Alt Mode lock is no longer held. This requires a new struct to hold the vdm data, altmode_vdm_event.
{
"affected": [],
"aliases": [
"CVE-2025-38268"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T08:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work\n\nA state check was previously added to tcpm_queue_vdm_unlocked to\nprevent a deadlock where the DisplayPort Alt Mode driver would be\nexecuting work and attempting to grab the tcpm_lock while the TCPM\nwas holding the lock and attempting to unregister the altmode, blocking\non the altmode driver\u0027s cancel_work_sync call.\n\nBecause the state check isn\u0027t protected, there is a small window\nwhere the Alt Mode driver could determine that the TCPM is\nin a ready state and attempt to grab the lock while the\nTCPM grabs the lock and changes the TCPM state to one that\ncauses the deadlock. The callstack is provided below:\n\n[110121.667392][ C7] Call trace:\n[110121.667396][ C7] __switch_to+0x174/0x338\n[110121.667406][ C7] __schedule+0x608/0x9f0\n[110121.667414][ C7] schedule+0x7c/0xe8\n[110121.667423][ C7] kernfs_drain+0xb0/0x114\n[110121.667431][ C7] __kernfs_remove+0x16c/0x20c\n[110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8\n[110121.667442][ C7] sysfs_remove_group+0x84/0xe8\n[110121.667450][ C7] sysfs_remove_groups+0x34/0x58\n[110121.667458][ C7] device_remove_groups+0x10/0x20\n[110121.667464][ C7] device_release_driver_internal+0x164/0x2e4\n[110121.667475][ C7] device_release_driver+0x18/0x28\n[110121.667484][ C7] bus_remove_device+0xec/0x118\n[110121.667491][ C7] device_del+0x1e8/0x4ac\n[110121.667498][ C7] device_unregister+0x18/0x38\n[110121.667504][ C7] typec_unregister_altmode+0x30/0x44\n[110121.667515][ C7] tcpm_reset_port+0xac/0x370\n[110121.667523][ C7] tcpm_snk_detach+0x84/0xb8\n[110121.667529][ C7] run_state_machine+0x4c0/0x1b68\n[110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4\n[110121.667544][ C7] kthread_worker_fn+0x10c/0x244\n[110121.667552][ C7] kthread+0x104/0x1d4\n[110121.667557][ C7] ret_from_fork+0x10/0x20\n\n[110121.667689][ C7] Workqueue: events dp_altmode_work\n[110121.667697][ C7] Call trace:\n[110121.667701][ C7] __switch_to+0x174/0x338\n[110121.667710][ C7] __schedule+0x608/0x9f0\n[110121.667717][ C7] schedule+0x7c/0xe8\n[110121.667725][ C7] schedule_preempt_disabled+0x24/0x40\n[110121.667733][ C7] __mutex_lock+0x408/0xdac\n[110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24\n[110121.667748][ C7] mutex_lock+0x40/0xec\n[110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4\n[110121.667764][ C7] typec_altmode_enter+0xdc/0x10c\n[110121.667769][ C7] dp_altmode_work+0x68/0x164\n[110121.667775][ C7] process_one_work+0x1e4/0x43c\n[110121.667783][ C7] worker_thread+0x25c/0x430\n[110121.667789][ C7] kthread+0x104/0x1d4\n[110121.667794][ C7] ret_from_fork+0x10/0x20\n\nChange tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work,\nwhich can perform the state check while holding the TCPM lock\nwhile the Alt Mode lock is no longer held. This requires a new\nstruct to hold the vdm data, altmode_vdm_event.",
"id": "GHSA-mg8g-g7c5-2wpm",
"modified": "2025-11-20T18:31:00Z",
"published": "2025-07-10T09:32:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1970d34b48cbeceb0c765984c9a6bb204c77f16a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/324d45e53f1a36c88bc649dc39e0c8300a41be0a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bdd712abefbec79176ab412d8c623e755c5d0ba"
}
],
"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-MGF2-2RM5-MVRF
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 15:33In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix soft lockup in retry_aligned_read()
When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup.
Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().
{
"affected": [],
"aliases": [
"CVE-2026-46051"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: fix soft lockup in retry_aligned_read()\n\nWhen retry_aligned_read() encounters an overlapped stripe, it releases\nthe stripe via raid5_release_stripe() which puts it on the lockless\nreleased_stripes llist. In the next raid5d loop iteration,\nrelease_stripe_list() drains the stripe onto handle_list (since\nSTRIPE_HANDLE is set by the original IO), but retry_aligned_read()\nruns before handle_active_stripes() and removes the stripe from\nhandle_list via find_get_stripe() -\u003e list_del_init(). This prevents\nhandle_stripe() from ever processing the stripe to resolve the\noverlap, causing an infinite loop and soft lockup.\n\nFix this by using __release_stripe() with temp_inactive_list instead\nof raid5_release_stripe() in the failure path, so the stripe does not\ngo through the released_stripes llist. This allows raid5d to break out\nof its loop, and the overlap will be resolved when the stripe is\neventually processed by handle_stripe().",
"id": "GHSA-mgf2-2rm5-mvrf",
"modified": "2026-06-16T15:33:41Z",
"published": "2026-05-27T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46051"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09880592f5a9dc73377d6eb5ac123537b5f8df49"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1985cb3247e87ff6b8ca4bc5f9626f4f51024507"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4166d5234fe8b6c3c7f796a6c198605356c5b355"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66df9f30673db66ac35145820a8e24906069ae57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f9f7c697474268d9ef9479df3ddfe7cdcfbbffc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80fc6ca2cbde018d52e13f305edcd643911bd94b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/883cc33b7af1c448663287f069ef9dfea001e90f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9055300e07d9d6800264d3c2560e1d0144689ca"
}
],
"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-MGVJ-6W35-QHJ7
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
PCI: Add missing bridge lock to pci_bus_lock()
One of the true positives that the cfg_access_lock lockdep effort identified is this sequence:
WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120
Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything but the bridge itself.
For the same motivation as adding:
bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);
to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock().
[bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]
{
"affected": [],
"aliases": [
"CVE-2024-46750"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T08:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Add missing bridge lock to pci_bus_lock()\n\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\n\n WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0x8c/0x190\n ? pci_bridge_secondary_bus_reset+0x5d/0x70\n ? report_bug+0x1f8/0x200\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? pci_bridge_secondary_bus_reset+0x5d/0x70\n pci_reset_bus+0x1d8/0x270\n vmd_probe+0x778/0xa10\n pci_device_probe+0x95/0x120\n\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\n\nFor the same motivation as adding:\n\n bridge = pci_upstream_bridge(dev);\n if (bridge)\n pci_dev_lock(bridge);\n\nto pci_reset_function() for the \"bus\" and \"cxl_bus\" reset cases, add\npci_dev_lock() for @bus-\u003eself to pci_bus_lock().\n\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]",
"id": "GHSA-mgvj-6w35-qhj7",
"modified": "2026-05-12T12:32:08Z",
"published": "2024-09-18T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04e85a3285b0e5c5af6fd2c0fd6e95ffecc01945"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0790b89c7e911003b8c50ae50e3ac7645de1fae9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7253b4fed46471cc247c6cacefac890a8472c083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78c6e39fef5c428960aff742149bba302dd46f5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81c68e218ab883dfa368460a59b674084c0240da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4e772898f8bf2e7e1cf661a12c60a5612c4afab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df77a678c33871a6e4ac5b54a71662f1d702335b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2355d513b89a2cb511b4ded0deb426cdb01acd0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MGX5-JRHQ-G7RG
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time.
Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless.
{
"affected": [],
"aliases": [
"CVE-2024-26686"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: do_task_stat: use sig-\u003estats_lock to gather the threads/children stats\n\nlock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call\ndo_task_stat() at the same time and the process has NR_THREADS, it will\nspin with irqs disabled O(NR_CPUS * NR_THREADS) time.\n\nChange do_task_stat() to use sig-\u003estats_lock to gather the statistics\noutside of -\u003esiglock protected section, in the likely case this code will\nrun lockless.",
"id": "GHSA-mgx5-jrhq-g7rg",
"modified": "2025-11-03T21:31:01Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26686"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c35d1914353799c54fa1843fe7dea6fcbcdbac5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3820b0fac7732a653bcc6f6ac20c1d72e697f8f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4fe85bdaabd63f8f8579b24a10ed597c9c482164"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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.