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-MHR3-X4XM-6J7C
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-38591"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix deadlock on SRQ async events.\n\nxa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/\nxa_erase_irq() to avoid deadlock.",
"id": "GHSA-mhr3-x4xm-6j7c",
"modified": "2025-11-03T21:31:09Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/605889754ee68aacf7c381938fcd5eb654e71822"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-MJ8C-437F-7PQG
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-19 21:31In the Linux kernel, the following vulnerability has been resolved:
block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work
Bios queued up in the zone write plug have already gone through all all preparation in the submit_bio path, including the freeze protection.
Submitting them through submit_bio_noacct_nocheck duplicates the work and can can cause deadlocks when freezing a queue with pending bio write plugs.
Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks.
{
"affected": [],
"aliases": [
"CVE-2025-38302"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T08:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: don\u0027t use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work\n\nBios queued up in the zone write plug have already gone through all all\npreparation in the submit_bio path, including the freeze protection.\n\nSubmitting them through submit_bio_noacct_nocheck duplicates the work\nand can can cause deadlocks when freezing a queue with pending bio\nwrite plugs.\n\nGo straight to -\u003esubmit_bio or blk_mq_submit_bio to bypass the\nsuperfluous extra freeze protection and checks.",
"id": "GHSA-mj8c-437f-7pqg",
"modified": "2025-11-19T21:31:16Z",
"published": "2025-07-10T09:32:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38302"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fccb6773b1f4f992e435582cf8e050de421b678"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ffae5d53f704d300cc73b06b4ea99e4507f7cf1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf625013d8741c01407bbb4a60c111b61b9fa69d"
}
],
"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-MM63-C923-GW6C
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-22 21:32In the Linux kernel, the following vulnerability has been resolved:
cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction
A hung_task problem shown below was found:
INFO: task kworker/0:0:8 blocked for more than 327 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Workqueue: events cgroup_bpf_release Call Trace: __schedule+0x5a2/0x2050 ? find_held_lock+0x33/0x100 ? wq_worker_sleeping+0x9e/0xe0 schedule+0x9f/0x180 schedule_preempt_disabled+0x25/0x50 __mutex_lock+0x512/0x740 ? cgroup_bpf_release+0x1e/0x4d0 ? cgroup_bpf_release+0xcf/0x4d0 ? process_scheduled_works+0x161/0x8a0 ? cgroup_bpf_release+0x1e/0x4d0 ? mutex_lock_nested+0x2b/0x40 ? __pfx_delay_tsc+0x10/0x10 mutex_lock_nested+0x2b/0x40 cgroup_bpf_release+0xcf/0x4d0 ? process_scheduled_works+0x161/0x8a0 ? trace_event_raw_event_workqueue_execute_start+0x64/0xd0 ? process_scheduled_works+0x161/0x8a0 process_scheduled_works+0x23a/0x8a0 worker_thread+0x231/0x5b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x14d/0x1c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x59/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
This issue can be reproduced by the following pressuse test: 1. A large number of cpuset cgroups are deleted. 2. Set cpu on and off repeatly. 3. Set watchdog_thresh repeatly. The scripts can be obtained at LINK mentioned above the signature.
The reason for this issue is cgroup_mutex and cpu_hotplug_lock are acquired in different tasks, which may lead to deadlock. It can lead to a deadlock through the following steps: 1. A large number of cpusets are deleted asynchronously, which puts a large number of cgroup_bpf_release works into system_wq. The max_active of system_wq is WQ_DFL_ACTIVE(256). Consequently, all active works are cgroup_bpf_release works, and many cgroup_bpf_release works will be put into inactive queue. As illustrated in the diagram, there are 256 (in the acvtive queue) + n (in the inactive queue) works. 2. Setting watchdog_thresh will hold cpu_hotplug_lock.read and put smp_call_on_cpu work into system_wq. However step 1 has already filled system_wq, 'sscs.work' is put into inactive queue. 'sscs.work' has to wait until the works that were put into the inacvtive queue earlier have executed (n cgroup_bpf_release), so it will be blocked for a while. 3. Cpu offline requires cpu_hotplug_lock.write, which is blocked by step 2. 4. Cpusets that were deleted at step 1 put cgroup_release works into cgroup_destroy_wq. They are competing to get cgroup_mutex all the time. When cgroup_metux is acqured by work at css_killed_work_fn, it will call cpuset_css_offline, which needs to acqure cpu_hotplug_lock.read. However, cpuset_css_offline will be blocked for step 3. 5. At this moment, there are 256 works in active queue that are cgroup_bpf_release, they are attempting to acquire cgroup_mutex, and as a result, all of them are blocked. Consequently, sscs.work can not be executed. Ultimately, this situation leads to four processes being blocked, forming a deadlock.
system_wq(step1) WatchDog(step2) cpu offline(step3) cgroup_destroy_wq(step4) ... 2000+ cgroups deleted asyn 256 actives + n inactives __lockup_detector_reconfigure P(cpu_hotplug_lock.read) put sscs.work into system_wq 256 + n + 1(sscs.work) sscs.work wait to be executed warting sscs.work finish percpu_down_write P(cpu_hotplug_lock.write) ...blocking... css_killed_work_fn P(cgroup_mutex) cpuset_css_offline P(cpu_hotplug_lock.read) ...blocking... 256 cgroup_bpf_release mutex_lock(&cgroup_mutex); ..blocking...
To fix the problem, place cgroup_bpf_release works on a dedicated workqueue which can break the loop and solve the problem. System wqs are for misc things which shouldn't create a large number of concurrent work items. If something is going to generate > ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-53054"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/bpf: use a dedicated workqueue for cgroup bpf destruction\n\nA hung_task problem shown below was found:\n\nINFO: task kworker/0:0:8 blocked for more than 327 seconds.\n\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\nWorkqueue: events cgroup_bpf_release\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x5a2/0x2050\n ? find_held_lock+0x33/0x100\n ? wq_worker_sleeping+0x9e/0xe0\n schedule+0x9f/0x180\n schedule_preempt_disabled+0x25/0x50\n __mutex_lock+0x512/0x740\n ? cgroup_bpf_release+0x1e/0x4d0\n ? cgroup_bpf_release+0xcf/0x4d0\n ? process_scheduled_works+0x161/0x8a0\n ? cgroup_bpf_release+0x1e/0x4d0\n ? mutex_lock_nested+0x2b/0x40\n ? __pfx_delay_tsc+0x10/0x10\n mutex_lock_nested+0x2b/0x40\n cgroup_bpf_release+0xcf/0x4d0\n ? process_scheduled_works+0x161/0x8a0\n ? trace_event_raw_event_workqueue_execute_start+0x64/0xd0\n ? process_scheduled_works+0x161/0x8a0\n process_scheduled_works+0x23a/0x8a0\n worker_thread+0x231/0x5b0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x14d/0x1c0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x59/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nThis issue can be reproduced by the following pressuse test:\n1. A large number of cpuset cgroups are deleted.\n2. Set cpu on and off repeatly.\n3. Set watchdog_thresh repeatly.\nThe scripts can be obtained at LINK mentioned above the signature.\n\nThe reason for this issue is cgroup_mutex and cpu_hotplug_lock are\nacquired in different tasks, which may lead to deadlock.\nIt can lead to a deadlock through the following steps:\n1. A large number of cpusets are deleted asynchronously, which puts a\n large number of cgroup_bpf_release works into system_wq. The max_active\n of system_wq is WQ_DFL_ACTIVE(256). Consequently, all active works are\n cgroup_bpf_release works, and many cgroup_bpf_release works will be put\n into inactive queue. As illustrated in the diagram, there are 256 (in\n the acvtive queue) + n (in the inactive queue) works.\n2. Setting watchdog_thresh will hold cpu_hotplug_lock.read and put\n smp_call_on_cpu work into system_wq. However step 1 has already filled\n system_wq, \u0027sscs.work\u0027 is put into inactive queue. \u0027sscs.work\u0027 has\n to wait until the works that were put into the inacvtive queue earlier\n have executed (n cgroup_bpf_release), so it will be blocked for a while.\n3. Cpu offline requires cpu_hotplug_lock.write, which is blocked by step 2.\n4. Cpusets that were deleted at step 1 put cgroup_release works into\n cgroup_destroy_wq. They are competing to get cgroup_mutex all the time.\n When cgroup_metux is acqured by work at css_killed_work_fn, it will\n call cpuset_css_offline, which needs to acqure cpu_hotplug_lock.read.\n However, cpuset_css_offline will be blocked for step 3.\n5. At this moment, there are 256 works in active queue that are\n cgroup_bpf_release, they are attempting to acquire cgroup_mutex, and as\n a result, all of them are blocked. Consequently, sscs.work can not be\n executed. Ultimately, this situation leads to four processes being\n blocked, forming a deadlock.\n\nsystem_wq(step1)\t\tWatchDog(step2)\t\t\tcpu offline(step3)\tcgroup_destroy_wq(step4)\n...\n2000+ cgroups deleted asyn\n256 actives + n inactives\n\t\t\t\t__lockup_detector_reconfigure\n\t\t\t\tP(cpu_hotplug_lock.read)\n\t\t\t\tput sscs.work into system_wq\n256 + n + 1(sscs.work)\nsscs.work wait to be executed\n\t\t\t\twarting sscs.work finish\n\t\t\t\t\t\t\t\tpercpu_down_write\n\t\t\t\t\t\t\t\tP(cpu_hotplug_lock.write)\n\t\t\t\t\t\t\t\t...blocking...\n\t\t\t\t\t\t\t\t\t\t\tcss_killed_work_fn\n\t\t\t\t\t\t\t\t\t\t\tP(cgroup_mutex)\n\t\t\t\t\t\t\t\t\t\t\tcpuset_css_offline\n\t\t\t\t\t\t\t\t\t\t\tP(cpu_hotplug_lock.read)\n\t\t\t\t\t\t\t\t\t\t\t...blocking...\n256 cgroup_bpf_release\nmutex_lock(\u0026cgroup_mutex);\n..blocking...\n\nTo fix the problem, place cgroup_bpf_release works on a dedicated\nworkqueue which can break the loop and solve the problem. System wqs are\nfor misc things which shouldn\u0027t create a large number of concurrent work\nitems. If something is going to generate \u003e\n---truncated---",
"id": "GHSA-mm63-c923-gw6c",
"modified": "2024-11-22T21:32:13Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53054"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d86cd70fc6a7ba18becb52ad8334d5ad3eca530"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/117932eea99b729ee5d12783601a4f7f5fd58a23"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dab3331523ba73db1345d19e6f586dcd5f6efb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71f14a9f5c7db72fdbc56e667d4ed42a1a760494"
}
],
"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-MMPF-HQVM-WHR2
Vulnerability from github – Published: 2023-01-13 00:30 – Updated: 2023-01-24 18:30An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series with MS-MPC or MS-MIC card and SRX Series allows an unauthenticated, network-based attacker to cause a flow processing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue occurs when SIP ALG is enabled and specific SIP messages are processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1 on MX Series, or SRX Series.
{
"affected": [],
"aliases": [
"CVE-2023-22412"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-13T00:15:00Z",
"severity": "HIGH"
},
"details": "An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series with MS-MPC or MS-MIC card and SRX Series allows an unauthenticated, network-based attacker to cause a flow processing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue occurs when SIP ALG is enabled and specific SIP messages are processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1 on MX Series, or SRX Series.",
"id": "GHSA-mmpf-hqvm-whr2",
"modified": "2023-01-24T18:30:31Z",
"published": "2023-01-13T00:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22412"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA70208"
}
],
"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-MMRM-HWXF-8J92
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-04-10 15:31In the Linux kernel, the following vulnerability has been resolved:
Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"
There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630).
This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products).
Revert the change to avoid additional guesswork around crashes.
This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.
{
"affected": [],
"aliases": [
"CVE-2025-22012"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu\"\n\nThere are reports that the pagetable walker cache coherency is not a\ngiven across the spectrum of SDM845/850 devices, leading to lock-ups\nand resets. It works fine on some devices (like the Dragonboard 845c,\nbut not so much on the Lenovo Yoga C630).\n\nThis unfortunately looks like a fluke in firmware development, where\nlikely somewhere in the vast hypervisor stack, a change to accommodate\nfor this was only introduced after the initial software release (which\noften serves as a baseline for products).\n\nRevert the change to avoid additional guesswork around crashes.\n\nThis reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.",
"id": "GHSA-mmrm-hwxf-8j92",
"modified": "2025-04-10T15:31:48Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e6e9fc90258a318d30b417bcccda908bb82ee9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f00db31d235946853fb430de8c6aa1295efc8353"
}
],
"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-MPM3-WJP6-8G7X
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-11-07 18:31In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix deadlock in AP/VLAN handling
Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.
To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can't easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn't used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case
{
"affected": [],
"aliases": [
"CVE-2021-47225"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix deadlock in AP/VLAN handling\n\nSyzbot reports that when you have AP_VLAN interfaces that are up\nand close the AP interface they belong to, we get a deadlock. No\nsurprise - since we dev_close() them with the wiphy mutex held,\nwhich goes back into the netdev notifier in cfg80211 and tries to\nacquire the wiphy mutex there.\n\nTo fix this, we need to do two things:\n 1) prevent changing iftype while AP_VLANs are up, we can\u0027t\n easily fix this case since cfg80211 already calls us with\n the wiphy mutex held, but change_interface() is relatively\n rare in drivers anyway, so changing iftype isn\u0027t used much\n (and userspace has to fall back to down/change/up anyway)\n 2) pull the dev_close() loop over VLANs out of the wiphy mutex\n section in the normal stop case",
"id": "GHSA-mpm3-wjp6-8g7x",
"modified": "2024-11-07T18:31:20Z",
"published": "2024-05-21T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47225"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8043903fcb72f545c52e3ec74d6fd82ef79ce7c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5befb224edbe53056c2c18999d630dafb4a08b9"
}
],
"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-MVC3-4Q88-Q347
Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone
btrfs_can_activate_zone() can be called with the device_list_mutex already held, which will lead to a deadlock:
insert_dev_extents() // Takes device_list_mutex
-> insert_dev_extent()-> btrfs_insert_empty_item()
-> btrfs_insert_empty_items()-> btrfs_search_slot()
-> btrfs_cow_block()-> __btrfs_cow_block()
-> btrfs_alloc_tree_block()-> btrfs_reserve_extent()
-> find_free_extent()-> find_free_extent_update_loop()
-> can_allocate_chunk()-> btrfs_can_activate_zone() // Takes device_list_mutex again
Instead of using the RCU on fs_devices->device_list we can use fs_devices->alloc_list, protected by the chunk_mutex to traverse the list of active devices.
We are in the chunk allocation thread. The newer chunk allocation happens from the devices in the fs_device->alloc_list protected by the chunk_mutex.
btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
Also, a device that reappears after the mount won't join the alloc_list yet and, it will be in the dev_list, which we don't want to consider in the context of the chunk alloc.
[15.166572] WARNING: possible recursive locking detected [15.167117] 5.17.0-rc6-dennis #79 Not tainted [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 is trying to acquire lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] but task is already holding lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] other info that might help us debug this: [15.167733] Possible unsafe locking scenario: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** DEADLOCK *** [15.171834] [15.171834] May be due to missing lock nesting notation [15.171834] [15.171834] 5 locks held by kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Call Trace: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49079"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone\n\nbtrfs_can_activate_zone() can be called with the device_list_mutex already\nheld, which will lead to a deadlock:\n\ninsert_dev_extents() // Takes device_list_mutex\n`-\u003e insert_dev_extent()\n `-\u003e btrfs_insert_empty_item()\n `-\u003e btrfs_insert_empty_items()\n `-\u003e btrfs_search_slot()\n `-\u003e btrfs_cow_block()\n `-\u003e __btrfs_cow_block()\n `-\u003e btrfs_alloc_tree_block()\n `-\u003e btrfs_reserve_extent()\n `-\u003e find_free_extent()\n `-\u003e find_free_extent_update_loop()\n `-\u003e can_allocate_chunk()\n `-\u003e btrfs_can_activate_zone() // Takes device_list_mutex again\n\nInstead of using the RCU on fs_devices-\u003edevice_list we\ncan use fs_devices-\u003ealloc_list, protected by the chunk_mutex to traverse\nthe list of active devices.\n\nWe are in the chunk allocation thread. The newer chunk allocation\nhappens from the devices in the fs_device-\u003ealloc_list protected by the\nchunk_mutex.\n\n btrfs_create_chunk()\n lockdep_assert_held(\u0026info-\u003echunk_mutex);\n gather_device_info\n list_for_each_entry(device, \u0026fs_devices-\u003ealloc_list, dev_alloc_list)\n\nAlso, a device that reappears after the mount won\u0027t join the alloc_list\nyet and, it will be in the dev_list, which we don\u0027t want to consider in\nthe context of the chunk alloc.\n\n [15.166572] WARNING: possible recursive locking detected\n [15.167117] 5.17.0-rc6-dennis #79 Not tainted\n [15.167487] --------------------------------------------\n [15.167733] kworker/u8:3/146 is trying to acquire lock:\n [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]\n [15.167733]\n [15.167733] but task is already holding lock:\n [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n [15.167733]\n [15.167733] other info that might help us debug this:\n [15.167733] Possible unsafe locking scenario:\n [15.167733]\n [15.171834] CPU0\n [15.171834] ----\n [15.171834] lock(\u0026fs_devs-\u003edevice_list_mutex);\n [15.171834] lock(\u0026fs_devs-\u003edevice_list_mutex);\n [15.171834]\n [15.171834] *** DEADLOCK ***\n [15.171834]\n [15.171834] May be due to missing lock nesting notation\n [15.171834]\n [15.171834] 5 locks held by kworker/u8:3/146:\n [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n [15.171834] #1: ffffc9000067be80 ((work_completion)(\u0026fs_info-\u003easync_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]\n [15.176244] #3: ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]\n [15.179641]\n [15.179641] stack backtrace:\n [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79\n [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014\n [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]\n [15.179641] Call Trace:\n [15.179641] \u003cTASK\u003e\n [15.179641] dump_stack_lvl+0x45/0x59\n [15.179641] __lock_acquire.cold+0x217/0x2b2\n [15.179641] lock_acquire+0xbf/0x2b0\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] __mutex_lock+0x8e/0x970\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? lock_is_held_type+0xd7/0x130\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? _raw_spin_unlock+0x24/0x40\n [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]\n [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs]\n [15.\n---truncated---",
"id": "GHSA-mvc3-4q88-q347",
"modified": "2025-10-14T21:30:25Z",
"published": "2025-10-14T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49079"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09e65ae515af2b24d6dc23af21719a3b41de83e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b9e66762aa0cda2a9c2d5542d64e04dac528fa6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/142f822bd945a7be442a2916ec6167cc102c4183"
}
],
"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-MVJQ-GQ62-VXRR
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 00:31In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix potential deadlock in cpu hotplug with osnoise
The following sequence may leads deadlock in cpu hotplug:
task1 task2 task3
----- ----- -----
mutex_lock(&interface_lock)
[CPU GOING OFFLINE]
cpus_write_lock();
osnoise_cpu_die();
kthread_stop(task3);
wait_for_completion();
osnoise_sleep();
mutex_lock(&interface_lock);
cpus_read_lock();
[DEAD LOCK]
Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).
{
"affected": [],
"aliases": [
"CVE-2026-31480"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix potential deadlock in cpu hotplug with osnoise\n\nThe following sequence may leads deadlock in cpu hotplug:\n\n task1 task2 task3\n ----- ----- -----\n\n mutex_lock(\u0026interface_lock)\n\n [CPU GOING OFFLINE]\n\n cpus_write_lock();\n osnoise_cpu_die();\n kthread_stop(task3);\n wait_for_completion();\n\n osnoise_sleep();\n mutex_lock(\u0026interface_lock);\n\n cpus_read_lock();\n\n [DEAD LOCK]\n\nFix by swap the order of cpus_read_lock() and mutex_lock(\u0026interface_lock).",
"id": "GHSA-mvjq-gq62-vxrr",
"modified": "2026-04-28T00:31:40Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31480"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03474a01c199de17a8e2d39b51df6beb9c76e831"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f9885732248d22f788e4992c739a98c88ab8a55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a41d4633cd2c15eb5ed31e8f3b16910e50a8c9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7aa095ce7d224308cb6979956f0de8607df93d4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf929c21eeed5bd39873fb14bfdfff963fa6f1da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef41a85a55022e27cdaebf22a6676910b66f65aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f278b8ebf7eba2a1699cfc7bf30dd3ef898d60d7"
}
],
"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-MW57-63XV-7MX2
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-02-19 18:31In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()
Callers of wdev_chandef() must hold the wiphy mutex.
But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes:
WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985
{
"affected": [],
"aliases": [
"CVE-2025-38643"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()\n\nCallers of wdev_chandef() must hold the wiphy mutex.\n\nBut the worker cfg80211_propagate_cac_done_wk() never takes the lock.\nWhich triggers the warning below with the mesh_peer_connected_dfs\ntest from hostapd and not (yet) released mac80211 code changes:\n\nWARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165\nModules linked in:\nCPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf\nWorkqueue: cfg80211 cfg80211_propagate_cac_done_wk\nStack:\n 00000000 00000001 ffffff00 6093267c\n 00000000 6002ec30 6d577c50 60037608\n 00000000 67e8d108 6063717b 00000000\nCall Trace:\n [\u003c6002ec30\u003e] ? _printk+0x0/0x98\n [\u003c6003c2b3\u003e] show_stack+0x10e/0x11a\n [\u003c6002ec30\u003e] ? _printk+0x0/0x98\n [\u003c60037608\u003e] dump_stack_lvl+0x71/0xb8\n [\u003c6063717b\u003e] ? wdev_chandef+0x60/0x165\n [\u003c6003766d\u003e] dump_stack+0x1e/0x20\n [\u003c6005d1b7\u003e] __warn+0x101/0x20f\n [\u003c6005d3a8\u003e] warn_slowpath_fmt+0xe3/0x15d\n [\u003c600b0c5c\u003e] ? mark_lock.part.0+0x0/0x4ec\n [\u003c60751191\u003e] ? __this_cpu_preempt_check+0x0/0x16\n [\u003c600b11a2\u003e] ? mark_held_locks+0x5a/0x6e\n [\u003c6005d2c5\u003e] ? warn_slowpath_fmt+0x0/0x15d\n [\u003c60052e53\u003e] ? unblock_signals+0x3a/0xe7\n [\u003c60052f2d\u003e] ? um_set_signals+0x2d/0x43\n [\u003c60751191\u003e] ? __this_cpu_preempt_check+0x0/0x16\n [\u003c607508b2\u003e] ? lock_is_held_type+0x207/0x21f\n [\u003c6063717b\u003e] wdev_chandef+0x60/0x165\n [\u003c605f89b4\u003e] regulatory_propagate_dfs_state+0x247/0x43f\n [\u003c60052f00\u003e] ? um_set_signals+0x0/0x43\n [\u003c605e6bfd\u003e] cfg80211_propagate_cac_done_wk+0x3a/0x4a\n [\u003c6007e460\u003e] process_scheduled_works+0x3bc/0x60e\n [\u003c6007d0ec\u003e] ? move_linked_works+0x4d/0x81\n [\u003c6007d120\u003e] ? assign_work+0x0/0xaa\n [\u003c6007f81f\u003e] worker_thread+0x220/0x2dc\n [\u003c600786ef\u003e] ? set_pf_worker+0x0/0x57\n [\u003c60087c96\u003e] ? to_kthread+0x0/0x43\n [\u003c6008ab3c\u003e] kthread+0x2d3/0x2e2\n [\u003c6007f5ff\u003e] ? worker_thread+0x0/0x2dc\n [\u003c6006c05b\u003e] ? calculate_sigpending+0x0/0x56\n [\u003c6003b37d\u003e] new_thread_handler+0x4a/0x64\nirq event stamp: 614611\nhardirqs last enabled at (614621): [\u003c00000000600bc96b\u003e] __up_console_sem+0x82/0xaf\nhardirqs last disabled at (614630): [\u003c00000000600bc92c\u003e] __up_console_sem+0x43/0xaf\nsoftirqs last enabled at (614268): [\u003c00000000606c55c6\u003e] __ieee80211_wake_queue+0x933/0x985\nsoftirqs last disabled at (614266): [\u003c00000000606c52d6\u003e] __ieee80211_wake_queue+0x643/0x985",
"id": "GHSA-mw57-63xv-7mx2",
"modified": "2026-02-19T18:31:42Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38643"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c5dee15239f3f3e31aa5c8808f18996c039e2c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a63523d3541eef4cf504a9682e6fbe94ffe79a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7022df2248c08c6f75a01714163ac902333bf3db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3d24038eb775f2f7a1dfef58d8e1dc444a12820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbce810607726408f889d3358f4780fd1436861e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/defe9ce121160788547e8e6ec4438ad8a14f40dd"
}
],
"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-MX24-9C8C-52XX
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2025-01-13 21:30In the Linux kernel, the following vulnerability has been resolved:
phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers
The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking.
Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers.
{
"affected": [],
"aliases": [
"CVE-2023-52505"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nphy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers\n\nThe protocol converter configuration registers PCC8, PCCC, PCCD\n(implemented by the driver), as well as others, control protocol\nconverters from multiple lanes (each represented as a different\nstruct phy). So, if there are simultaneous calls to phy_set_mode_ext()\nto lanes sharing the same PCC register (either for the \"old\" or for the\n\"new\" protocol), corruption of the values programmed to hardware is\npossible, because lynx_28g_rmw() has no locking.\n\nAdd a spinlock in the struct lynx_28g_priv shared by all lanes, and take\nthe global spinlock from the phy_ops :: set_mode() implementation. There\nare no other callers which modify PCC registers.",
"id": "GHSA-mx24-9c8c-52xx",
"modified": "2025-01-13T21:30:46Z",
"published": "2024-03-03T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52505"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/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.