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-W52V-VRVM-954M
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
cachefiles: add missing lock protection when polling
Add missing lock protection in poll routine when iterating xarray, otherwise:
Even with RCU read lock held, only the slot of the radix tree is ensured to be pinned there, while the data structure (e.g. struct cachefiles_req) stored in the slot has no such guarantee. The poll routine will iterate the radix tree and dereference cachefiles_req accordingly. Thus RCU read lock is not adequate in this case and spinlock is needed here.
{
"affected": [],
"aliases": [
"CVE-2024-42250"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T16:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: add missing lock protection when polling\n\nAdd missing lock protection in poll routine when iterating xarray,\notherwise:\n\nEven with RCU read lock held, only the slot of the radix tree is\nensured to be pinned there, while the data structure (e.g. struct\ncachefiles_req) stored in the slot has no such guarantee. The poll\nroutine will iterate the radix tree and dereference cachefiles_req\naccordingly. Thus RCU read lock is not adequate in this case and\nspinlock is needed here.",
"id": "GHSA-w52v-vrvm-954m",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-07T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bb6bd3dd6f382dfd36220d4b210a0c77c066651"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8eadcab7f3dd809edbe5ae20533ff843dfea3a07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/97cfd5e20ddc2e33e16ce369626ce76c9a475fd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf5bb09e742a9cf6349127e868329a8f69b7a014"
},
{
"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-W5FV-M4RQ-PGG2
Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-01-15 21:31An Improper Locking vulnerability in the GTP plugin of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (Dos).
If an SRX Series device receives a specifically malformed GPRS Tunnelling Protocol (GTP) Modify Bearer Request message, a lock is acquired and never released. This results in other threads not being able to acquire a lock themselves, causing a watchdog timeout leading to FPC crash and restart. This issue leads to a complete traffic outage until the device has automatically recovered.
This issue affects Junos OS on SRX Series:
- all versions before 22.4R3-S8,
- 23.2 versions before 23.2R2-S5,
- 23.4 versions before 23.4R2-S6,
- 24.2 versions before 24.2R2-S3,
- 24.4 versions before 24.4R2-S2,
- 25.2 versions before 25.2R1-S1, 25.2R2.
{
"affected": [],
"aliases": [
"CVE-2026-21914"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-15T21:16:07Z",
"severity": "HIGH"
},
"details": "An Improper Locking vulnerability in the GTP plugin of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (Dos).\n\nIf an SRX Series device receives a specifically malformed GPRS Tunnelling Protocol (GTP) Modify Bearer Request message, a lock is acquired and never released. This results in other threads not being able to acquire a lock themselves, causing a watchdog timeout leading to FPC crash and restart. This issue leads to a complete traffic outage until the device has automatically recovered.\n\nThis issue affects Junos OS on SRX Series:\n\n * all versions before 22.4R3-S8,\n * 23.2 versions before 23.2R2-S5,\n * 23.4 versions before 23.4R2-S6,\n * 24.2 versions before 24.2R2-S3,\n * 24.4 versions before 24.4R2-S2,\n * 25.2 versions before 25.2R1-S1, 25.2R2.",
"id": "GHSA-w5fv-m4rq-pgg2",
"modified": "2026-01-15T21:31:48Z",
"published": "2026-01-15T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21914"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA106015"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA106015"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:A/V:X/RE:M/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W5PR-8RVR-3PCP
Vulnerability from github – Published: 2022-05-02 03:53 – Updated: 2024-02-15 21:31A certain Red Hat patch for net/ipv4/route.c in the Linux kernel 2.6.18 on Red Hat Enterprise Linux (RHEL) 5 allows remote attackers to cause a denial of service (deadlock) via crafted packets that force collisions in the IPv4 routing hash table, and trigger a routing "emergency" in which a hash chain is too long. NOTE: this is related to an issue in the Linux kernel before 2.6.31, when the kernel routing cache is disabled, involving an uninitialized pointer and a panic.
{
"affected": [],
"aliases": [
"CVE-2009-4272"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-01-27T17:30:00Z",
"severity": "HIGH"
},
"details": "A certain Red Hat patch for net/ipv4/route.c in the Linux kernel 2.6.18 on Red Hat Enterprise Linux (RHEL) 5 allows remote attackers to cause a denial of service (deadlock) via crafted packets that force collisions in the IPv4 routing hash table, and trigger a routing \"emergency\" in which a hash chain is too long. NOTE: this is related to an issue in the Linux kernel before 2.6.31, when the kernel routing cache is disabled, involving an uninitialized pointer and a panic.",
"id": "GHSA-w5pr-8rvr-3pcp",
"modified": "2024-02-15T21:31:24Z",
"published": "2022-05-02T03:53:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4272"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2010:0046"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2010:0095"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2009-4272"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=545411"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/55808"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11167"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A7026"
},
{
"type": "WEB",
"url": "https://rhn.redhat.com/errata/RHSA-2010-0046.html"
},
{
"type": "WEB",
"url": "https://rhn.redhat.com/errata/RHSA-2010-0095.html"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=73e42897e8e5619eacb787d2ce69be12f47cfc21"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=b6280b47a7a42970d098a3059f4ebe7e55e90d8d"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=73e42897e8e5619eacb787d2ce69be12f47cfc21"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6280b47a7a42970d098a3059f4ebe7e55e90d8d"
},
{
"type": "WEB",
"url": "http://support.avaya.com/css/P8/documents/100073666"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.31"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/01/20/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/01/20/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W6Q8-WF67-MW74
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq
storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning:
[ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---
{
"affected": [],
"aliases": [
"CVE-2022-49986"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq\n\nstorvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it\ndoesn\u0027t need to make forward progress under memory pressure. Marking this\nworkqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a\nnon-WQ_MEM_RECLAIM workqueue. In the current state it causes the following\nwarning:\n\n[ 14.506347] ------------[ cut here ]------------\n[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn\n[ 14.506360] WARNING: CPU: 0 PID: 8 at \u003c-snip-\u003ekernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130\n[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu\n[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun\n[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130\n\t\t\u003c-snip-\u003e\n[ 14.506408] Call Trace:\n[ 14.506412] __flush_work+0xf1/0x1c0\n[ 14.506414] __cancel_work_timer+0x12f/0x1b0\n[ 14.506417] ? kernfs_put+0xf0/0x190\n[ 14.506418] cancel_delayed_work_sync+0x13/0x20\n[ 14.506420] disk_block_events+0x78/0x80\n[ 14.506421] del_gendisk+0x3d/0x2f0\n[ 14.506423] sr_remove+0x28/0x70\n[ 14.506427] device_release_driver_internal+0xef/0x1c0\n[ 14.506428] device_release_driver+0x12/0x20\n[ 14.506429] bus_remove_device+0xe1/0x150\n[ 14.506431] device_del+0x167/0x380\n[ 14.506432] __scsi_remove_device+0x11d/0x150\n[ 14.506433] scsi_remove_device+0x26/0x40\n[ 14.506434] storvsc_remove_lun+0x40/0x60\n[ 14.506436] process_one_work+0x209/0x400\n[ 14.506437] worker_thread+0x34/0x400\n[ 14.506439] kthread+0x121/0x140\n[ 14.506440] ? process_one_work+0x400/0x400\n[ 14.506441] ? kthread_park+0x90/0x90\n[ 14.506443] ret_from_fork+0x35/0x40\n[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---",
"id": "GHSA-w6q8-wf67-mw74",
"modified": "2025-11-14T18:31:23Z",
"published": "2025-06-18T12:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49986"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46fcb0fc884db78a0384be92cc2a51927e6581b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/828f57ac75eaccd6607ee4d1468d34e983e32c68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4c928ace9a123629eeb14ec5d7ee8f73e5ac668"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b692c238ddfa61f00d97c4c1f021425d132ba96f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd2a50d0a097a42b6de283377da98ff757505120"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d957e7ffb2c72410bcc1a514153a46719255a5da"
}
],
"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-W89W-9482-VJ48
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-28 15:30In the Linux kernel, the following vulnerability has been resolved:
net: hinic: avoid kernel hung in hinic_get_stats64()
When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung.
The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180
And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324
When getting device stats from bond, kernel will call bond_get_stats().
It first holds the spinlock bond->stats_lock, and then call
hinic_get_stats64() to collect hinic device's stats.
However, hinic_get_stats64() calls down(&nic_dev->mgmt_lock) to
protect its critical section, which may schedule current task out.
And if system is under high pressure, the task cannot be woken up
immediately, which eventually triggers kernel hung panic.
Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local variable in hinic_get_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok.
{
"affected": [],
"aliases": [
"CVE-2022-50174"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hinic: avoid kernel hung in hinic_get_stats64()\n\nWhen using hinic device as a bond slave device, and reading device stats\nof master bond device, the kernel may hung.\n\nThe kernel panic calltrace as follows:\nKernel panic - not syncing: softlockup: hung tasks\nCall trace:\n native_queued_spin_lock_slowpath+0x1ec/0x31c\n dev_get_stats+0x60/0xcc\n dev_seq_printf_stats+0x40/0x120\n dev_seq_show+0x1c/0x40\n seq_read_iter+0x3c8/0x4dc\n seq_read+0xe0/0x130\n proc_reg_read+0xa8/0xe0\n vfs_read+0xb0/0x1d4\n ksys_read+0x70/0xfc\n __arm64_sys_read+0x20/0x30\n el0_svc_common+0x88/0x234\n do_el0_svc+0x2c/0x90\n el0_svc+0x1c/0x30\n el0_sync_handler+0xa8/0xb0\n el0_sync+0x148/0x180\n\nAnd the calltrace of task that actually caused kernel hungs as follows:\n __switch_to+124\n __schedule+548\n schedule+72\n schedule_timeout+348\n __down_common+188\n __down+24\n down+104\n hinic_get_stats64+44 [hinic]\n dev_get_stats+92\n bond_get_stats+172 [bonding]\n dev_get_stats+92\n dev_seq_printf_stats+60\n dev_seq_show+24\n seq_read_iter+964\n seq_read+220\n proc_reg_read+164\n vfs_read+172\n ksys_read+108\n __arm64_sys_read+28\n el0_svc_common+132\n do_el0_svc+40\n el0_svc+24\n el0_sync_handler+164\n el0_sync+324\n\nWhen getting device stats from bond, kernel will call bond_get_stats().\nIt first holds the spinlock bond-\u003estats_lock, and then call\nhinic_get_stats64() to collect hinic device\u0027s stats.\nHowever, hinic_get_stats64() calls `down(\u0026nic_dev-\u003emgmt_lock)` to\nprotect its critical section, which may schedule current task out.\nAnd if system is under high pressure, the task cannot be woken up\nimmediately, which eventually triggers kernel hung panic.\n\nSince previous patch has replaced hinic_dev.tx_stats/rx_stats with local\nvariable in hinic_get_stats64(), there is nothing need to be protected\nby lock, so just removing down()/up() is ok.",
"id": "GHSA-w89w-9482-vj48",
"modified": "2025-11-28T15:30:29Z",
"published": "2025-06-18T12:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50174"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ba59bbe4f306bb6ee15753db0a40564c0eb7909"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/693f31dc91568e61047fd2980a8235e856cd9ce8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98f9fcdee35add80505b6c73f72de5f750d5c03c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e74f3097a9c713ce855cda07713393bcc23a005d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fced5bce712122654ec8a20356342698cce104d2"
}
],
"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-W939-6X76-94VC
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: displayport: Fix deadlock
This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.
{
"affected": [],
"aliases": [
"CVE-2025-37967"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T17:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix deadlock\n\nThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock\nfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connector\nmutex is only locked if a connection is established and the partner pointer\nis valid. This resolves a deadlock scenario where\nucsi_displayport_remove_partner holds con-\u003emutex waiting for\ndp_altmode_work to complete while dp_altmode_work attempts to acquire it.",
"id": "GHSA-w939-6x76-94vc",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37967"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/364618c89d4c57c85e5fc51a2446cd939bf57802"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5924b324468845fc795bd76f588f51d7ab4f202d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61fc1a8e1e10cc784cab5829930838aaf1d37af5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/962ce9028ca6eb450d5c205238a3ee27de9d214d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f32451ca4cb7dc53f2a0e2e66b84d34162747eb7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4bd982563c2fd41ec9ca6c517c392d759db801c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.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-W93H-CV9G-F692
Vulnerability from github – Published: 2025-10-22 21:31 – Updated: 2025-10-22 21:31In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero
It is possible to disable VFs while the PF driver is processing requests from the VF driver. This can result in a panic.
BUG: unable to handle kernel paging request at 000000000000106c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- - Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe] Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff 01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c 00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002 RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006 RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780 R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020 R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80 FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? ttwu_do_wakeup+0x19/0x140 ? try_to_wake_up+0x1cd/0x550 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf] ixgbe_msix_other+0x17e/0x310 [ixgbe] __handle_irq_event_percpu+0x40/0x180 handle_irq_event_percpu+0x30/0x80 handle_irq_event+0x36/0x53 handle_edge_irq+0x82/0x190 handle_irq+0x1c/0x30 do_IRQ+0x49/0xd0 common_interrupt+0xf/0xf
This can be eventually be reproduced with the following script:
while : do echo 63 > /sys/class/net//device/sriov_numvfs sleep 1 echo 0 > /sys/class/net//device/sriov_numvfs sleep 1 done
Add lock when disabling SR-IOV to prevent process VF mailbox communication.
{
"affected": [],
"aliases": [
"CVE-2022-49584"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbe: Add locking to prevent panic when setting sriov_numvfs to zero\n\nIt is possible to disable VFs while the PF driver is processing requests\nfrom the VF driver. This can result in a panic.\n\nBUG: unable to handle kernel paging request at 000000000000106c\nPGD 0 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- -\nHardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020\nRIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]\nCode: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff\n01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 \u003c41\u003e 80 7c 24 4c\n00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a\nRSP: 0018:ffffb337869f8df8 EFLAGS: 00010002\nRAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b\nRDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006\nRBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780\nR10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020\nR13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80\nFS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u003cIRQ\u003e\n ? ttwu_do_wakeup+0x19/0x140\n ? try_to_wake_up+0x1cd/0x550\n ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf]\n ixgbe_msix_other+0x17e/0x310 [ixgbe]\n __handle_irq_event_percpu+0x40/0x180\n handle_irq_event_percpu+0x30/0x80\n handle_irq_event+0x36/0x53\n handle_edge_irq+0x82/0x190\n handle_irq+0x1c/0x30\n do_IRQ+0x49/0xd0\n common_interrupt+0xf/0xf\n\nThis can be eventually be reproduced with the following script:\n\nwhile :\ndo\n echo 63 \u003e /sys/class/net/\u003cdevname\u003e/device/sriov_numvfs\n sleep 1\n echo 0 \u003e /sys/class/net/\u003cdevname\u003e/device/sriov_numvfs\n sleep 1\ndone\n\nAdd lock when disabling SR-IOV to prevent process VF mailbox communication.",
"id": "GHSA-w93h-cv9g-f692",
"modified": "2025-10-22T21:31:17Z",
"published": "2025-10-22T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49584"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/031af9e617a6f51075d97e56fc9e712c7dde2508"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16f929a5e76fd047fd8697e1e568bdd7d771955c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e53834ce541d4fe271cdcca7703e50be0a44f8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d925d2dc82cec2bcbd8625457645d8a548ab22e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b82de63f8f817b5735480293dda8e92ba8170c52"
}
],
"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-W94F-XH79-Q24V
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2025-03-27 21:31In the Linux kernel, the following vulnerability has been resolved:
spi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks
The ->runtime_suspend() and ->runtime_resume() callbacks are not expected to call spi_controller_suspend() and spi_controller_resume(). Remove calls to those in the cadence-qspi driver.
Those helpers have two roles currently: - They stop/start the queue, including dealing with the kworker. - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It requires acquiring ctlr->bus_lock_mutex.
Step one is irrelevant because cadence-qspi is not queued. Step two however has two implications: - A deadlock occurs, because ->runtime_resume() is called in a context where the lock is already taken (in the ->exec_op() callback, where the usage count is incremented). - It would disallow all operations once the device is auto-suspended.
Here is a brief call tree highlighting the mutex deadlock:
spi_mem_exec_op() ... spi_mem_access_start() mutex_lock(&ctlr->bus_lock_mutex)
cqspi_exec_mem_op()
pm_runtime_resume_and_get()
cqspi_resume()
spi_controller_resume()
mutex_lock(&ctlr->bus_lock_mutex)
...
spi_mem_access_end()
mutex_unlock(&ctlr->bus_lock_mutex)
...
{
"affected": [],
"aliases": [
"CVE-2024-26806"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks\n\nThe -\u003eruntime_suspend() and -\u003eruntime_resume() callbacks are not\nexpected to call spi_controller_suspend() and spi_controller_resume().\nRemove calls to those in the cadence-qspi driver.\n\nThose helpers have two roles currently:\n - They stop/start the queue, including dealing with the kworker.\n - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It\n requires acquiring ctlr-\u003ebus_lock_mutex.\n\nStep one is irrelevant because cadence-qspi is not queued. Step two\nhowever has two implications:\n - A deadlock occurs, because -\u003eruntime_resume() is called in a context\n where the lock is already taken (in the -\u003eexec_op() callback, where\n the usage count is incremented).\n - It would disallow all operations once the device is auto-suspended.\n\nHere is a brief call tree highlighting the mutex deadlock:\n\nspi_mem_exec_op()\n ...\n spi_mem_access_start()\n mutex_lock(\u0026ctlr-\u003ebus_lock_mutex)\n\n cqspi_exec_mem_op()\n pm_runtime_resume_and_get()\n cqspi_resume()\n spi_controller_resume()\n mutex_lock(\u0026ctlr-\u003ebus_lock_mutex)\n ...\n\n spi_mem_access_end()\n mutex_unlock(\u0026ctlr-\u003ebus_lock_mutex)\n ...",
"id": "GHSA-w94f-xh79-q24v",
"modified": "2025-03-27T21:31:04Z",
"published": "2024-04-04T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26806"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/041562ebc4759c9932b59a06527f8753b86da365"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/959043afe53ae80633e810416cee6076da6e91c6"
}
],
"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-WG44-XVPW-F949
Vulnerability from github – Published: 2023-10-11 21:33 – Updated: 2024-04-04 08:35there is a possible use-after-free write 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.
{
"affected": [],
"aliases": [
"CVE-2023-3781"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-11T21:15:09Z",
"severity": "HIGH"
},
"details": "there is a possible use-after-free write 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.\n\n",
"id": "GHSA-wg44-xvpw-f949",
"modified": "2024-04-04T08:35:00Z",
"published": "2023-10-11T21:33:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3781"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-10-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-WG8C-GHQW-WQ88
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-11-04 18:31In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()
Instead of attempting the same mutex twice, lock and unlock it.
This bug has been detected by the Clang thread-safety analyzer.
{
"affected": [],
"aliases": [
"CVE-2025-22098"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()\n\nInstead of attempting the same mutex twice, lock and unlock it.\n\nThis bug has been detected by the Clang thread-safety analyzer.",
"id": "GHSA-wg8c-ghqw-wq88",
"modified": "2025-11-04T18:31:31Z",
"published": "2025-04-16T15:34:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f988cd2f65175e79349961a43a9deb115174784"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a8d53aa5b7d2a89cda598239d08423bd66920f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f887685ee0eb4ef716391355568181230338f6eb"
}
],
"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.