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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-5QC2-5C25-4M38
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-08-13 15:34In the Linux kernel, the following vulnerability has been resolved:
i2c: tegra: fix pm_runtime leak on mutex_lock failure
If tegra_i2c_mutex_lock() fails, the function returns without calling pm_runtime_put(), leaking the runtime PM reference acquired by the preceding pm_runtime_get_sync(). This prevents the device from ever entering runtime suspend.
Add the missing pm_runtime_put() before returning on lock failure.
{
"affected": [],
"aliases": [
"CVE-2026-64171"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: tegra: fix pm_runtime leak on mutex_lock failure\n\nIf tegra_i2c_mutex_lock() fails, the function returns without calling\npm_runtime_put(), leaking the runtime PM reference acquired by the\npreceding pm_runtime_get_sync(). This prevents the device from ever\nentering runtime suspend.\n\nAdd the missing pm_runtime_put() before returning on lock failure.",
"id": "GHSA-5qc2-5c25-4m38",
"modified": "2026-08-13T15:34:17Z",
"published": "2026-07-19T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64171"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57cf4e8d6a57dc2ef5810f4852a23ba4c71b74bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f7ed203b39004c02479a9156089d87d1ac2c1d8"
}
],
"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-5RCM-HXRF-MW27
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.
{
"affected": [],
"aliases": [
"CVE-2025-38058"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T10:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\n__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock\n\n... or we risk stealing final mntput from sync umount - raising mnt_count\nafter umount(2) has verified that victim is not busy, but before it\nhas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn\u0027t see\nthat it\u0027s safe to quietly undo mnt_count increment and leaves dropping\nthe reference to caller, where it\u0027ll be a full-blown mntput().\n\nCheck under mount_lock is needed; leaving the current one done before\ntaking that makes no sense - it\u0027s nowhere near common enough to bother\nwith.",
"id": "GHSA-5rcm-hxrf-mw27",
"modified": "2026-05-12T15:30:53Z",
"published": "2025-06-18T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38058"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/250cf3693060a5f803c5f1ddc082bb06b16112a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/628fb00195ce21a90cf9e4e3d105cd9e58f77b40"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cafd7266fa02e0863bacbf872fe635c0b9725eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b0915e72b3cf52474dcee0b24a2f99d93e604a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b55996939c71a3e1a38f3cdc6a8859797efc9083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b89eb56a378b7b2c1176787fc228d0a57172bdd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8ece4ced3b051e656c77180df2e69e19e24edc1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-5RMR-VQFV-62Q6
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-07 00:30In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock().
Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine)
{
"affected": [],
"aliases": [
"CVE-2022-49765"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:15:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: use a dedicated spinlock for trans_fd\n\nShamelessly copying the explanation from Tetsuo Handa\u0027s suggested\npatch[1] (slightly reworded):\nsyzbot is reporting inconsistent lock state in p9_req_put()[2],\nfor p9_tag_remove() from p9_req_put() from IRQ context is using\nspin_lock_irqsave() on \"struct p9_client\"-\u003elock but trans_fd\n(not from IRQ context) is using spin_lock().\n\nSince the locks actually protect different things in client.c and in\ntrans_fd.c, just replace trans_fd.c\u0027s lock by a new one specific to the\ntransport (client.c\u0027s protect the idr for fid/tag allocations,\nwhile trans_fd.c\u0027s protects its own req list and request status field\nthat acts as the transport\u0027s state machine)",
"id": "GHSA-5rmr-vqfv-62q6",
"modified": "2025-11-07T00:30:26Z",
"published": "2025-05-01T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49765"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/296ab4a813841ba1d5f40b03190fd1bd8f25aab0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43bbadb7e4636dc02f6a283c2a39e6438e6173cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/717b9b4f38703d7f5293059e3a242d16f76fa045"
}
],
"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-5W6J-RMQ5-X4X9
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now.
This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed.
{
"affected": [],
"aliases": [
"CVE-2022-49272"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock\n\nsyzbot caught a potential deadlock between the PCM\nruntime-\u003ebuffer_mutex and the mm-\u003emmap_lock. It was brought by the\nrecent fix to cover the racy read/write and other ioctls, and in that\ncommit, I overlooked a (hopefully only) corner case that may take the\nrevert lock, namely, the OSS mmap. The OSS mmap operation\nexceptionally allows to re-configure the parameters inside the OSS\nmmap syscall, where mm-\u003emmap_mutex is already held. Meanwhile, the\ncopy_from/to_user calls at read/write operations also take the\nmm-\u003emmap_lock internally, hence it may lead to a AB/BA deadlock.\n\nA similar problem was already seen in the past and we fixed it with a\nrefcount (in commit b248371628aa). The former fix covered only the\ncall paths with OSS read/write and OSS ioctls, while we need to cover\nthe concurrent access via both ALSA and OSS APIs now.\n\nThis patch addresses the problem above by replacing the buffer_mutex\nlock in the read/write operations with a refcount similar as we\u0027ve\nused for OSS. The new field, runtime-\u003ebuffer_accessing, keeps the\nnumber of concurrent read/write operations. Unlike the former\nbuffer_mutex protection, this protects only around the\ncopy_from/to_user() calls; the other codes are basically protected by\nthe PCM stream lock. The refcount can be a negative, meaning blocked\nby the ioctls. If a negative value is seen, the read/write aborts\nwith -EBUSY. In the ioctl side, OTOH, they check this refcount, too,\nand set to a negative value for blocking unless it\u0027s already being\naccessed.",
"id": "GHSA-5w6j-rmq5-x4x9",
"modified": "2025-09-22T21:30:16Z",
"published": "2025-09-22T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49272"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9017201e8d8c6d1472273361389ed431188584a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9661bf674d6a82b76e4ae424438a8ce1e3ed855d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/abedf0d08c79d76da0d6fa0d5dbbc98871dcbc2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc55cfd5718c7c23e5524582e9fa70b4d10f2433"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be9813ad2fc8f0885f5ce6925af0d993ce5da4e5"
}
],
"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-5XQ3-RMW6-5P48
Vulnerability from github – Published: 2024-04-17 18:31 – Updated: 2025-09-16 18:31In the Linux kernel, the following vulnerability has been resolved:
Revert "drm/amd: flush any delayed gfxoff on suspend entry"
commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again.
Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock.
This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
{
"affected": [],
"aliases": [
"CVE-2024-26916"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T16:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"drm/amd: flush any delayed gfxoff on suspend entry\"\n\ncommit ab4750332dbe (\"drm/amdgpu/sdma5.2: add begin/end_use ring\ncallbacks\") caused GFXOFF control to be used more heavily and the\ncodepath that was removed from commit 0dee72639533 (\"drm/amd: flush any\ndelayed gfxoff on suspend entry\") now can be exercised at suspend again.\n\nUsers report that by using GNOME to suspend the lockscreen trigger will\ncause SDMA traffic and the system can deadlock.\n\nThis reverts commit 0dee726395333fea833eaaf838bc80962df886c8.",
"id": "GHSA-5xq3-rmw6-5p48",
"modified": "2025-09-16T18:31:18Z",
"published": "2024-04-17T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26916"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65158edb0a3a8df23197d52cd24287e39eaf95d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/916361685319098f696b798ef1560f69ed96e934"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/caa2565a2e13899be31f7b1e069e6465d3e2adb0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d855ceb6a5fde668c5431156bc60fae0cc52b764"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff70e6ff6fc2413caf33410af7462d1f584d927e"
}
],
"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-5XQG-J6JP-J9G5
Vulnerability from github – Published: 2025-01-15 15:31 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking
If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...
We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C).
The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fast_io, .disable_locking, etc.
mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex.
However, __setup_irq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock.
It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcp_pinconf_get/set.
mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock().
The accesses to the regmap from mcp23s08_probe_one() do not need additional locking.
In all remaining places where the regmap is accessed, except mcp_pinconf_get/set(), the driver already takes mcp->lock.
This patch adds locking in mcp_pinconf_get/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above.
{
"affected": [],
"aliases": [
"CVE-2024-57889"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-15T13:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking\n\nIf a device uses MCP23xxx IO expander to receive IRQs, the following\nbug can happen:\n\n BUG: sleeping function called from invalid context\n at kernel/locking/mutex.c:283\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...\n preempt_count: 1, expected: 0\n ...\n Call Trace:\n ...\n __might_resched+0x104/0x10e\n __might_sleep+0x3e/0x62\n mutex_lock+0x20/0x4c\n regmap_lock_mutex+0x10/0x18\n regmap_update_bits_base+0x2c/0x66\n mcp23s08_irq_set_type+0x1ae/0x1d6\n __irq_set_trigger+0x56/0x172\n __setup_irq+0x1e6/0x646\n request_threaded_irq+0xb6/0x160\n ...\n\nWe observed the problem while experimenting with a touchscreen driver which\nused MCP23017 IO expander (I2C).\n\nThe regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from\nconcurrent accesses, which is the default for regmaps without .fast_io,\n.disable_locking, etc.\n\nmcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter\nlocks the mutex.\n\nHowever, __setup_irq() locks desc-\u003elock spinlock before calling these\nfunctions. As a result, the system tries to lock the mutex whole holding\nthe spinlock.\n\nIt seems, the internal regmap locks are not needed in this driver at all.\nmcp-\u003elock seems to protect the regmap from concurrent accesses already,\nexcept, probably, in mcp_pinconf_get/set.\n\nmcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under\nchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes\nmcp-\u003elock and enables regmap caching, so that the potentially slow I2C\naccesses are deferred until chip_bus_unlock().\n\nThe accesses to the regmap from mcp23s08_probe_one() do not need additional\nlocking.\n\nIn all remaining places where the regmap is accessed, except\nmcp_pinconf_get/set(), the driver already takes mcp-\u003elock.\n\nThis patch adds locking in mcp_pinconf_get/set() and disables internal\nlocking in the regmap config. Among other things, it fixes the sleeping\nin atomic context described above.",
"id": "GHSA-5xqg-j6jp-j9g5",
"modified": "2025-11-03T21:32:12Z",
"published": "2025-01-15T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57889"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"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-6246-6GX2-C2HW
Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-03-17 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix lock dependency warning with srcu
====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted
kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0
but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0
-> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0
-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80
-> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0
other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
sync(srcu);
{
"affected": [],
"aliases": [
"CVE-2023-52632"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix lock dependency warning with srcu\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.5.0-kfd-yangp #2289 Not tainted\n------------------------------------------------------\nkworker/0:2/996 is trying to acquire lock:\n (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0\n\nbut task is already holding lock:\n ((work_completion)(\u0026svms-\u003edeferred_list_work)){+.+.}-{0:0}, at:\n\tprocess_one_work+0x211/0x560\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #3 ((work_completion)(\u0026svms-\u003edeferred_list_work)){+.+.}-{0:0}:\n __flush_work+0x88/0x4f0\n svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]\n svm_range_set_attr+0xd6/0x14c0 [amdgpu]\n kfd_ioctl+0x1d1/0x630 [amdgpu]\n __x64_sys_ioctl+0x88/0xc0\n\n-\u003e #2 (\u0026info-\u003elock#2){+.+.}-{3:3}:\n __mutex_lock+0x99/0xc70\n amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]\n restore_process_helper+0x22/0x80 [amdgpu]\n restore_process_worker+0x2d/0xa0 [amdgpu]\n process_one_work+0x29b/0x560\n worker_thread+0x3d/0x3d0\n\n-\u003e #1 ((work_completion)(\u0026(\u0026process-\u003erestore_work)-\u003ework)){+.+.}-{0:0}:\n __flush_work+0x88/0x4f0\n __cancel_work_timer+0x12c/0x1c0\n kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]\n __mmu_notifier_release+0xad/0x240\n exit_mmap+0x6a/0x3a0\n mmput+0x6a/0x120\n do_exit+0x322/0xb90\n do_group_exit+0x37/0xa0\n __x64_sys_exit_group+0x18/0x20\n do_syscall_64+0x38/0x80\n\n-\u003e #0 (srcu){.+.+}-{0:0}:\n __lock_acquire+0x1521/0x2510\n lock_sync+0x5f/0x90\n __synchronize_srcu+0x4f/0x1a0\n __mmu_notifier_release+0x128/0x240\n exit_mmap+0x6a/0x3a0\n mmput+0x6a/0x120\n svm_range_deferred_list_work+0x19f/0x350 [amdgpu]\n process_one_work+0x29b/0x560\n worker_thread+0x3d/0x3d0\n\nother info that might help us debug this:\nChain exists of:\n srcu --\u003e \u0026info-\u003elock#2 --\u003e (work_completion)(\u0026svms-\u003edeferred_list_work)\n\nPossible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock((work_completion)(\u0026svms-\u003edeferred_list_work));\n lock(\u0026info-\u003elock#2);\n\t\t\tlock((work_completion)(\u0026svms-\u003edeferred_list_work));\n sync(srcu);",
"id": "GHSA-6246-6gx2-c2hw",
"modified": "2025-03-17T15:31:37Z",
"published": "2024-04-02T09:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52632"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94"
}
],
"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-625Q-77GV-32CR
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed().
{
"affected": [],
"aliases": [
"CVE-2024-56532"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: us122l: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThe loop of us122l-\u003emmap_count check is dropped as well. The check is\nuseless for the asynchronous operation with *_when_closed().",
"id": "GHSA-625q-77gv-32cr",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/020cbc4d7414f0962004213e2b7bc5cc607e9ec7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2938dd2648522336133c151dd67bb9bf01cbd390"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75f418b249d84021865eaa59515d3ed9b75ce4d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a48bd2184b142c92a4e17eac074c61fcf975bc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b27924dc8d7f8a8c35e521287d4ccb9a006e597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5c530e4d70f64b1114f2cc29ac690ba7ac4a38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7df09bb348016943f56b09dcaafe221e3f73947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc778ad3e495333eebda36fe91d5b2c93109cc16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf0aa35a7cb8602cccf2387712114e836f65c154"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"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-62F3-XHHG-6P74
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-18 21:32In the Linux kernel, the following vulnerability has been resolved:
s390/mm: Fix in_atomic() handling in do_secure_storage_access()
Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off.
It is not allowed to take the mmap_lock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page).
{
"affected": [],
"aliases": [
"CVE-2025-38359"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Fix in_atomic() handling in do_secure_storage_access()\n\nKernel user spaces accesses to not exported pages in atomic context\nincorrectly try to resolve the page fault.\nWith debug options enabled call traces like this can be seen:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39\npreempt_count: 1, expected: 0\nRCU nest depth: 0, expected: 0\nINFO: lockdep is turned off.\nPreemption disabled at:\n[\u003c00000383ea47cfa2\u003e] copy_page_from_iter_atomic+0xa2/0x8a0\nCPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39\nTainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT\nTainted: [W]=WARN\nHardware name: IBM 3931 A01 703 (LPAR)\nCall Trace:\n [\u003c00000383e990d282\u003e] dump_stack_lvl+0xa2/0xe8\n [\u003c00000383e99bf152\u003e] __might_resched+0x292/0x2d0\n [\u003c00000383eaa7c374\u003e] down_read+0x34/0x2d0\n [\u003c00000383e99432f8\u003e] do_secure_storage_access+0x108/0x360\n [\u003c00000383eaa724b0\u003e] __do_pgm_check+0x130/0x220\n [\u003c00000383eaa842e4\u003e] pgm_check_handler+0x114/0x160\n [\u003c00000383ea47d028\u003e] copy_page_from_iter_atomic+0x128/0x8a0\n([\u003c00000383ea47d016\u003e] copy_page_from_iter_atomic+0x116/0x8a0)\n [\u003c00000383e9c45eae\u003e] generic_perform_write+0x16e/0x310\n [\u003c00000383e9eb87f4\u003e] ext4_buffered_write_iter+0x84/0x160\n [\u003c00000383e9da0de4\u003e] vfs_write+0x1c4/0x460\n [\u003c00000383e9da123c\u003e] ksys_write+0x7c/0x100\n [\u003c00000383eaa7284e\u003e] __do_syscall+0x15e/0x280\n [\u003c00000383eaa8417e\u003e] system_call+0x6e/0x90\nINFO: lockdep is turned off.\n\nIt is not allowed to take the mmap_lock while in atomic context. Therefore\nhandle such a secure storage access fault as if the accessed page is not\nmapped: the uaccess function will return -EFAULT, and the caller has to\ndeal with this. Usually this means that the access is retried in process\ncontext, which allows to resolve the page fault (or in this case export the\npage).",
"id": "GHSA-62f3-xhhg-6p74",
"modified": "2025-11-18T21:32:29Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38359"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11709abccf93b08adde95ef313c300b0d4bc28f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2e317dfd2d1fe416c77315d17c5d57dbe374915"
}
],
"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-62JP-4QC2-X9XX
Vulnerability from github – Published: 2022-05-01 02:21 – Updated: 2024-02-15 21:31The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.
{
"affected": [],
"aliases": [
"CVE-2005-3847"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-11-27T00:03:00Z",
"severity": "MODERATE"
},
"details": "The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.",
"id": "GHSA-62jp-4qc2-x9xx",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T02:21:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-3847"
},
{
"type": "WEB",
"url": "http://lists.suse.de/archive/suse-security-announce/2006-Feb/0010.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112430346613450\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112508422716574\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19038"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19374"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2006/dsa-1017"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git%3Ba=blob%3Bh=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5%3Bhb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd%3Bf=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=blob;h=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5;hb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd;f=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commitdiff%3Bh=dd12f48d4e8774415b528d3991ae47c28f26e1ac%3Bhp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dd12f48d4e8774415b528d3991ae47c28f26e1ac;hp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/16856"
}
],
"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.