CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
724 vulnerabilities reference this CWE, most recent first.
GHSA-JPJ8-HW92-VQGG
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix deadlocks between devlink and netdev instance locks
In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering.
The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock.
But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover
The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout
Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.
{
"affected": [],
"aliases": [
"CVE-2026-45907"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlocks between devlink and netdev instance locks\n\nIn the mentioned \"Fixes\" commit, various work tasks triggering devlink\nhealth reporter recovery were switched to use netdev_trylock to protect\nagainst concurrent tear down of the channels being recovered. But this\nhad the side effect of introducing potential deadlocks because of\nincorrect lock ordering.\n\nThe correct lock order is described by the init flow:\nprobe_one -\u003e mlx5_init_one (acquires devlink lock)\n-\u003e mlx5_init_one_devl_locked -\u003e mlx5_register_device\n-\u003e mlx5_rescan_drivers_locked -...-\u003e mlx5e_probe -\u003e _mlx5e_probe\n-\u003e register_netdev (acquires rtnl lock)\n-\u003e register_netdevice (acquires netdev lock)\n=\u003e devlink lock -\u003e rtnl lock -\u003e netdev lock.\n\nBut in the current recovery flow, the order is wrong:\nmlx5e_tx_err_cqe_work (acquires netdev lock)\n-\u003e mlx5e_reporter_tx_err_cqe -\u003e mlx5e_health_report\n-\u003e devlink_health_report (acquires devlink lock =\u003e boom!)\n-\u003e devlink_health_reporter_recover\n-\u003e mlx5e_tx_reporter_recover -\u003e mlx5e_tx_reporter_recover_from_ctx\n-\u003e mlx5e_tx_reporter_err_cqe_recover\n\nThe same pattern exists in:\nmlx5e_reporter_rx_timeout\nmlx5e_reporter_tx_ptpsq_unhealthy\nmlx5e_reporter_tx_timeout\n\nFix these by moving the netdev_trylock calls from the work handlers\nlower in the call stack, in the respective recovery functions, where\nthey are actually necessary.",
"id": "GHSA-jpj8-hw92-vqgg",
"modified": "2026-06-24T18:32:27Z",
"published": "2026-05-27T15:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45907"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9"
}
],
"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-JQX2-5F2V-644H
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: move wait_on_sem() out of spinlock
With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled.
Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled.
{
"affected": [],
"aliases": [
"CVE-2026-43253"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: move wait_on_sem() out of spinlock\n\nWith iommu.strict=1, the existing completion wait path can cause soft\nlockups under stressed environment, as wait_on_sem() busy-waits under the\nspinlock with interrupts disabled.\n\nMove the completion wait in iommu_completion_wait() out of the spinlock.\nwait_on_sem() only polls the hardware-updated cmd_sem and does not require\niommu-\u003elock, so holding the lock during the busy wait unnecessarily\nincreases contention and extends the time with interrupts disabled.",
"id": "GHSA-jqx2-5f2v-644h",
"modified": "2026-05-08T15:31:18Z",
"published": "2026-05-06T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43253"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/496269d12072ecb219826485bdbec70c92a8eef5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/715c263119fd1b918a9fcbd8a36ea5b604a46324"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2a0cac10597068567d336e85fa3cbdbe8ca62bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e15768e68820142077bbca402d8e902f64ade1b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2f65b28d802a667119147444ec2ae33eebf9a58"
}
],
"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-JW27-39XW-8FJX
Vulnerability from github – Published: 2025-12-12 21:31 – Updated: 2026-03-20 18:31A memory corruption issue was addressed with improved lock state checking. This issue is fixed in watchOS 26.1, iOS 18.7.2 and iPadOS 18.7.2, macOS Tahoe 26.1, visionOS 26.1, tvOS 26.1, macOS Sonoma 14.8.2, macOS Sequoia 15.7.2, iOS 26.1 and iPadOS 26.1. A malicious application may cause unexpected changes in memory shared between processes.
{
"affected": [],
"aliases": [
"CVE-2025-43510"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-12T21:15:55Z",
"severity": "HIGH"
},
"details": "A memory corruption issue was addressed with improved lock state checking. This issue is fixed in watchOS 26.1, iOS 18.7.2 and iPadOS 18.7.2, macOS Tahoe 26.1, visionOS 26.1, tvOS 26.1, macOS Sonoma 14.8.2, macOS Sequoia 15.7.2, iOS 26.1 and iPadOS 26.1. A malicious application may cause unexpected changes in memory shared between processes.",
"id": "GHSA-jw27-39xw-8fjx",
"modified": "2026-03-20T18:31:15Z",
"published": "2025-12-12T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43510"
},
{
"type": "WEB",
"url": "https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125632"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125633"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125634"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125635"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125636"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125637"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125638"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125639"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-43510"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JW2V-CQ5X-Q68G
Vulnerability from github – Published: 2026-01-20 16:30 – Updated: 2026-02-02 22:21Summary
Pterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle.
However, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time.
As a result a server would be able to create more databases, allocations, or backups than configured.
Impact
A malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pterodactyl/panel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69198"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-400",
"CWE-413",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-20T16:30:17Z",
"nvd_published_at": "2026-01-19T19:16:03Z",
"severity": "MODERATE"
},
"details": "### Summary\nPterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle.\n\nHowever, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time.\n\nAs a result a server would be able to create more databases, allocations, or backups than configured.\n\n### Impact\nA malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system.",
"id": "GHSA-jw2v-cq5x-q68g",
"modified": "2026-02-02T22:21:44Z",
"published": "2026-01-20T16:30:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-jw2v-cq5x-q68g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69198"
},
{
"type": "WEB",
"url": "https://github.com/pterodactyl/panel/commit/09caa0d4995bd924b53b9a9e9b4883ac27bd5607"
},
{
"type": "PACKAGE",
"url": "https://github.com/pterodactyl/panel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Pterodactyl improperly locks resources allowing raced queries to create more resources than alloted"
}
GHSA-M24R-P59V-Q652
Vulnerability from github – Published: 2023-07-18 18:30 – Updated: 2024-04-04 06:13A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2023-0160"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-18T17:15:11Z",
"severity": "MODERATE"
},
"details": "A deadlock flaw was found in the Linux kernel\u2019s BPF subsystem. This flaw allows a local user to potentially crash the system.",
"id": "GHSA-m24r-p59v-q652",
"modified": "2024-04-04T06:13:54Z",
"published": "2023-07-18T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0160"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-0160"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2159764"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com"
}
],
"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"
}
]
}
GHSA-M2V9-W374-5HJ9
Vulnerability from github – Published: 2024-04-25 19:50 – Updated: 2025-01-14 16:37Summary
Prior to v0.3.0, __default__() functions did not respect the @nonreentrancy decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.
A contract search was additionally performed and no vulnerable contracts were found in production.
PoC
@external
@payable
@nonreentrant("default")
def __default__():
pass
after codegen:
[seq,
[if, [lt, calldatasize, 4], [goto, fallback]],
[mstore, 28, [calldataload, 0]],
[with, _func_sig, [mload, 0], seq],
[seq_unchecked,
[label, fallback],
[seq,
pass,
# Line 5
pass,
pass,
# Line 4
stop]]],
Impact
No vulnerable production contracts were found. Additionally, using a lock on a default function is a very sparsely used pattern. As such, the impact is low.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.16"
},
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32648"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T19:50:35Z",
"nvd_published_at": "2024-04-25T18:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\nPrior to v0.3.0, `__default__()` functions did not respect the `@nonreentrancy` decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.\n\nA contract search was additionally performed and no vulnerable contracts were found in production.\n\n### PoC\n```vyper\n@external\n@payable\n@nonreentrant(\"default\")\ndef __default__():\n pass\n```\n\nafter codegen:\n```\n[seq,\n [if, [lt, calldatasize, 4], [goto, fallback]],\n [mstore, 28, [calldataload, 0]],\n [with, _func_sig, [mload, 0], seq],\n [seq_unchecked,\n [label, fallback],\n [seq,\n pass,\n # Line 5\n pass,\n pass,\n # Line 4\n stop]]],\n```\n\n### Impact\nNo vulnerable production contracts were found. Additionally, using a lock on a `default` function is a very sparsely used pattern. As such, the impact is `low`.\n",
"id": "GHSA-m2v9-w374-5hj9",
"modified": "2025-01-14T16:37:11Z",
"published": "2024-04-25T19:50:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-m2v9-w374-5hj9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32648"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/issues/2455"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/93287e5ac184b53b395c907d40701f721daf8177"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-163.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vyperlang/vyper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "vyper default functions don\u0027t respect nonreentrancy keys"
}
GHSA-M484-77R4-H4VF
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-08-21 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: Fix a deadlock in the error handler
The following deadlock has been observed on a test setup:
-
All tags allocated
-
The SCSI error handler calls ufshcd_eh_host_reset_handler()
-
ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
-
ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request.
{
"affected": [],
"aliases": [
"CVE-2021-47622"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: Fix a deadlock in the error handler\n\nThe following deadlock has been observed on a test setup:\n\n - All tags allocated\n\n - The SCSI error handler calls ufshcd_eh_host_reset_handler()\n\n - ufshcd_eh_host_reset_handler() queues work that calls\n ufshcd_err_handler()\n\n - ufshcd_err_handler() locks up as follows:\n\nWorkqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt\nCall trace:\n __switch_to+0x298/0x5d8\n __schedule+0x6cc/0xa94\n schedule+0x12c/0x298\n blk_mq_get_tag+0x210/0x480\n __blk_mq_alloc_request+0x1c8/0x284\n blk_get_request+0x74/0x134\n ufshcd_exec_dev_cmd+0x68/0x640\n ufshcd_verify_dev_init+0x68/0x35c\n ufshcd_probe_hba+0x12c/0x1cb8\n ufshcd_host_reset_and_restore+0x88/0x254\n ufshcd_reset_and_restore+0xd0/0x354\n ufshcd_err_handler+0x408/0xc58\n process_one_work+0x24c/0x66c\n worker_thread+0x3e8/0xa4c\n kthread+0x150/0x1b4\n ret_from_fork+0x10/0x30\n\nFix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved\nrequest.",
"id": "GHSA-m484-77r4-h4vf",
"modified": "2024-08-21T18:31:26Z",
"published": "2024-07-16T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47622"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768"
}
],
"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-M4W5-F9XF-8FGR
Vulnerability from github – Published: 2025-02-09 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
gpio: xilinx: Convert gpio_lock to raw spinlock
irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking.
This fixes the following lockdep splat:
[ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)
{
"affected": [],
"aliases": [
"CVE-2025-21684"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-09T12:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: xilinx: Convert gpio_lock to raw spinlock\n\nirq_chip functions may be called in raw spinlock context. Therefore, we\nmust also use a raw spinlock for our own internal locking.\n\nThis fixes the following lockdep splat:\n\n[ 5.349336] =============================\n[ 5.353349] [ BUG: Invalid wait context ]\n[ 5.357361] 6.13.0-rc5+ #69 Tainted: G W\n[ 5.363031] -----------------------------\n[ 5.367045] kworker/u17:1/44 is trying to lock:\n[ 5.371587] ffffff88018b02c0 (\u0026chip-\u003egpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.380079] other info that might help us debug this:\n[ 5.385138] context-{5:5}\n[ 5.387762] 5 locks held by kworker/u17:1/44:\n[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)\n[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)\n[ 5.411528] #2: ffffff880172c900 (\u0026dev-\u003emutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)\n[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)\n[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)\n[ 5.436472] stack backtrace:\n[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69\n[ 5.448690] Tainted: [W]=WARN\n[ 5.451656] Hardware name: xlnx,zynqmp (DT)\n[ 5.455845] Workqueue: events_unbound deferred_probe_work_func\n[ 5.461699] Call trace:\n[ 5.464147] show_stack+0x18/0x24 C\n[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)\n[ 5.471501] dump_stack (lib/dump_stack.c:130)\n[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)\n[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)\n[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)\n[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)\n[ 5.497645] irq_startup (kernel/irq/chip.c:270)\n[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)\n[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)",
"id": "GHSA-m4w5-f9xf-8fgr",
"modified": "2025-11-03T21:32:35Z",
"published": "2025-02-09T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21684"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d25041d4a3b2af64c888cf762362b2528ba59294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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-M5Q9-GX2F-VVF3
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-09-06 18:31In the Linux kernel, the following vulnerability has been resolved:
xen: privcmd: Switch from mutex to spinlock for irqfds
irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock.
Fix it by switching over to a spin lock.
{
"affected": [],
"aliases": [
"CVE-2024-44957"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(\u0026ctx-\u003ewqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can\u0027t use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock.",
"id": "GHSA-m5q9-gx2f-vvf3",
"modified": "2024-09-06T18:31:28Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c"
}
],
"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-M65F-MMQM-4FQ6
Vulnerability from github – Published: 2024-08-22 03:31 – Updated: 2024-09-12 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from __writeback_inodes_sb_nr():
$ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)
The trace produced in dmesg looks like the following:
[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability.
We can not just lock the sb->s_umount semaphore before calling writeback_inodes_sb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of writeback_inodes_sb(), because that will try to read lock sb->s_umount and then will only call writeback_inodes_sb() if it was able to lock it. This is fine because the cases where it can't read lock sb->s_umount are during a filesystem unmount or during a filesystem freeze - in those cases sb->s_umount is write locked and sync_filesystem() is called, which calls writeback_inodes_sb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a number of pages different from LONG_MAX, for example matching the number of delalloc bytes we currently have, in ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-48920"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T02:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: get rid of warning on transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, during almost every transaction\ncommit we trigger a warning from __writeback_inodes_sb_nr():\n\n $ cat fs/fs-writeback.c:\n (...)\n static void __writeback_inodes_sb_nr(struct super_block *sb, ...\n {\n (...)\n WARN_ON(!rwsem_is_locked(\u0026sb-\u003es_umount));\n (...)\n }\n (...)\n\nThe trace produced in dmesg looks like the following:\n\n [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3\n [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif\n [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186\n [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3\n [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)\n [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246\n [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000\n [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50\n [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000\n [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488\n [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460\n [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000\n [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0\n [947.571072] Call Trace:\n [947.572354] \u003cTASK\u003e\n [947.573266] btrfs_commit_transaction+0x1f1/0x998\n [947.576785] ? start_transaction+0x3ab/0x44e\n [947.579867] ? schedule_timeout+0x8a/0xdd\n [947.582716] transaction_kthread+0xe9/0x156\n [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407\n [947.590104] kthread+0x131/0x139\n [947.592168] ? set_kthread_struct+0x32/0x32\n [947.595174] ret_from_fork+0x22/0x30\n [947.597561] \u003c/TASK\u003e\n [947.598553] ---[ end trace 644721052755541c ]---\n\nThis is because we started using writeback_inodes_sb() to flush delalloc\nwhen committing a transaction (when using -o flushoncommit), in order to\navoid deadlocks with filesystem freeze operations. This change was made\nby commit ce8ea7cc6eb313 (\"btrfs: don\u0027t call btrfs_start_delalloc_roots\nin flushoncommit\"). After that change we started producing that warning,\nand every now and then a user reports this since the warning happens too\noften, it spams dmesg/syslog, and a user is unsure if this reflects any\nproblem that might compromise the filesystem\u0027s reliability.\n\nWe can not just lock the sb-\u003es_umount semaphore before calling\nwriteback_inodes_sb(), because that would at least deadlock with\nfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()\nis called while we are holding that semaphore in write mode, and that can\ntrigger a transaction commit, resulting in a deadlock. It would also\ntrigger the same type of deadlock in the unmount path. Possibly, it could\nalso introduce some other locking dependencies that lockdep would report.\n\nTo fix this call try_to_writeback_inodes_sb() instead of\nwriteback_inodes_sb(), because that will try to read lock sb-\u003es_umount\nand then will only call writeback_inodes_sb() if it was able to lock it.\nThis is fine because the cases where it can\u0027t read lock sb-\u003es_umount\nare during a filesystem unmount or during a filesystem freeze - in those\ncases sb-\u003es_umount is write locked and sync_filesystem() is called, which\ncalls writeback_inodes_sb(). In other words, in all cases where we can\u0027t\ntake a read lock on sb-\u003es_umount, writeback is already being triggered\nelsewhere.\n\nAn alternative would be to call btrfs_start_delalloc_roots() with a\nnumber of pages different from LONG_MAX, for example matching the number\nof delalloc bytes we currently have, in \n---truncated---",
"id": "GHSA-m65f-mmqm-4fq6",
"modified": "2024-09-12T15:32:59Z",
"published": "2024-08-22T03:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48920"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/850a77c999b81dd2724efd2684068d6f90db8c16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0f0cf8341e34e5d2265bfd3a7ad68342da1e2aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4d044dbffcd570351f21c747fc77ff90aed7f2e"
}
],
"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.