CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
693 vulnerabilities reference this CWE, most recent first.
GHSA-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"
}
]
}
GHSA-MHGR-C53R-GX3P
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30In the Linux kernel, the following vulnerability has been resolved:
USB: dummy-hcd: Fix locking/synchronization error
Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind.
These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first.
The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented.
The fix is to increment dum->callback_usage before calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.
{
"affected": [],
"aliases": [
"CVE-2026-43327"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: dummy-hcd: Fix locking/synchronization error\n\nSyzbot testing was able to provoke an addressing exception and crash\nin the usb_gadget_udc_reset() routine in\ndrivers/usb/gadgets/udc/core.c, resulting from the fact that the\nroutine was called with a second (\"driver\") argument of NULL. The bad\ncaller was set_link_state() in dummy_hcd.c, and the problem arose\nbecause of a race between a USB reset and driver unbind.\n\nThese sorts of races were not supposed to be possible; commit\n7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"),\nalong with a few followup commits, was written specifically to prevent\nthem. As it turns out, there are (at least) two errors remaining in\nthe code. Another patch will address the second error; this one is\nconcerned with the first.\n\nThe error responsible for the syzbot crash occurred because the\nstop_activity() routine will sometimes drop and then re-acquire the\ndum-\u003elock spinlock. A call to stop_activity() occurs in\nset_link_state() when handling an emulated USB reset, after the test\nof dum-\u003eints_enabled and before the increment of dum-\u003ecallback_usage.\nThis allowed another thread (doing a driver unbind) to sneak in and\ngrab the spinlock, and then clear dum-\u003eints_enabled and dum-\u003edriver.\nNormally this other thread would have to wait for dum-\u003ecallback_usage\nto go down to 0 before it would clear dum-\u003edriver, but in this case it\ndidn\u0027t have to wait since dum-\u003ecallback_usage had not yet been\nincremented.\n\nThe fix is to increment dum-\u003ecallback_usage _before_ calling\nstop_activity() instead of after. Then the thread doing the unbind\nwill not clear dum-\u003edriver until after the call to\nusb_gadget_udc_reset() safely returns and dum-\u003ecallback_usage has been\ndecremented again.",
"id": "GHSA-mhgr-c53r-gx3p",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43327"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/218886b2ef2dea7627d3700ab0abaf4bf9d1161f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/616a63ff495df12863692ab3f9f7b84e3fa7a66d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6350c7dd33ab481ef41c931a238361490c32d15c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69ab97a693251d6a6093e630060a3c744fd58524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/791966f85b439b261bf19865cf1c07c065ffb4b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/805b1833d6ed6da5086e610578a28e71bb54fbbb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc97fb5969177cccce2e23b31298df220fc7570d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efbd9441f1e769a7aae1813d497cec09cbdff031"
}
],
"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-MHPR-V3HF-GCXG
Vulnerability from github – Published: 2024-07-29 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock
When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume.
{
"affected": [],
"aliases": [
"CVE-2024-42085"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T17:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock\n\nWhen config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system\nto enter suspend status with below command:\necho mem \u003e /sys/power/state\nThere will be a deadlock issue occurring. Detailed invoking path as\nbelow:\ndwc3_suspend_common()\n spin_lock_irqsave(\u0026dwc-\u003elock, flags); \u003c-- 1st\n dwc3_gadget_suspend(dwc);\n dwc3_gadget_soft_disconnect(dwc);\n spin_lock_irqsave(\u0026dwc-\u003elock, flags); \u003c-- 2nd\nThis issue is exposed by commit c7ebd8149ee5 (\"usb: dwc3: gadget: Fix\nNULL pointer dereference in dwc3_gadget_suspend\") that removes the code\nof checking whether dwc-\u003egadget_driver is NULL or not. It causes the\nfollowing code is executed and deadlock occurs when trying to get the\nspinlock. In fact, the root cause is the commit 5265397f9442(\"usb: dwc3:\nRemove DWC3 locking during gadget suspend/resume\") that forgot to remove\nthe lock of otg mode. So, remove the redundant lock of otg mode during\ngadget suspend/resume.",
"id": "GHSA-mhpr-v3hf-gcxg",
"modified": "2025-11-04T00:31:05Z",
"published": "2024-07-29T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42085"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17e2956633ca560b95f1cbbb297cfc2adf650649"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7026576e89094aa9a0062aa6d10cba18aa99944c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7838de15bb700c2898a7d741db9b1f3cbc86c136"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8731a0b180f6b5d52397c7aeea6eda9511a467a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d77e2b5104c51d3668b9717c825a4a06998efe63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1274cfab183e69a7c7bafffcb4f50703c876276"
},
{
"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"
}
]
}
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.