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-7M37-CX35-QGMR
Vulnerability from github – Published: 2023-01-04 18:31 – Updated: 2023-01-11 23:47Uniswap Universal Router before 1.1.0 mishandles reentrancy. This would have allowed theft of funds.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@uniswap/universal-router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-48216"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-11T23:47:54Z",
"nvd_published_at": "2023-01-04T16:15:00Z",
"severity": "HIGH"
},
"details": "Uniswap Universal Router before 1.1.0 mishandles reentrancy. This would have allowed theft of funds.",
"id": "GHSA-7m37-cx35-qgmr",
"modified": "2023-01-11T23:47:54Z",
"published": "2023-01-04T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48216"
},
{
"type": "WEB",
"url": "https://github.com/Uniswap/universal-router/pull/189"
},
{
"type": "WEB",
"url": "https://github.com/Uniswap/universal-router/commit/d82c6685ef566d9b280651c99f4b93a8454c08a8"
},
{
"type": "PACKAGE",
"url": "https://github.com/Uniswap/universal-router"
},
{
"type": "WEB",
"url": "https://github.com/Uniswap/universal-router/compare/v1.0.1...v1.1.0"
},
{
"type": "WEB",
"url": "https://media.dedaub.com/uniswap-bug-bounty-1625d8ff04ae"
},
{
"type": "WEB",
"url": "https://twitter.com/dedaub/status/1610058814094450694"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uniswap Universal Router Incorrect Authorization vulnerability"
}
GHSA-7M6P-MVHJ-8V99
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-10-28 21:30In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()
Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock (through crypto_exit_scomp_ops_async()).
On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through crypto_scomp_init_tfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.
The above dependencies can cause an ABBA deadlock. For example in the following scenario:
(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)
(2) Task A is descheduled
(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock
(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK
Since there is no requirement to call crypto_free_acomp() with the per-CPU acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is unlocked. Also move the acomp_request_free() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future.
With this, only setting acomp_ctx fields to NULL occurs with the mutex held. This is similar to how zswap_cpu_comp_prepare() only initializes acomp_ctx fields with the mutex held, after performing all allocations before holding the mutex.
Opportunistically, move the NULL check on acomp_ctx so that it takes place before the mutex dereference.
{
"affected": [],
"aliases": [
"CVE-2025-22030"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()\n\nCurrently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding\nthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock\n(through crypto_exit_scomp_ops_async()).\n\nOn the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through\ncrypto_scomp_init_tfm()), and then allocates memory. If the allocation\nresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.\n\nThe above dependencies can cause an ABBA deadlock. For example in the\nfollowing scenario:\n\n(1) Task A running on CPU #1:\n crypto_alloc_acomp_node()\n Holds scomp_lock\n Enters reclaim\n Reads per_cpu_ptr(pool-\u003eacomp_ctx, 1)\n\n(2) Task A is descheduled\n\n(3) CPU #1 goes offline\n zswap_cpu_comp_dead(CPU #1)\n Holds per_cpu_ptr(pool-\u003eacomp_ctx, 1))\n Calls crypto_free_acomp()\n Waits for scomp_lock\n\n(4) Task A running on CPU #2:\n Waits for per_cpu_ptr(pool-\u003eacomp_ctx, 1) // Read on CPU #1\n DEADLOCK\n\nSince there is no requirement to call crypto_free_acomp() with the per-CPU\nacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is\nunlocked. Also move the acomp_request_free() and kfree() calls for\nconsistency and to avoid any potential sublte locking dependencies in the\nfuture.\n\nWith this, only setting acomp_ctx fields to NULL occurs with the mutex\nheld. This is similar to how zswap_cpu_comp_prepare() only initializes\nacomp_ctx fields with the mutex held, after performing all allocations\nbefore holding the mutex.\n\nOpportunistically, move the NULL check on acomp_ctx so that it takes place\nbefore the mutex dereference.",
"id": "GHSA-7m6p-mvhj-8v99",
"modified": "2025-10-28T21:30:29Z",
"published": "2025-04-16T15:34:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/717d9c35deff6c33235693171bacbb03e9643fa4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/747e3eec1d7d124ea90ed3d7b85369df8b4e36d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8d18000e9d2d97aaf105f5f9b3b0e8a6fbf8b96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c11bcbc0a517acf69282c8225059b2a8ac5fe628"
}
],
"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-7MXG-CX88-PJ6R
Vulnerability from github – Published: 2022-12-07 03:30 – Updated: 2022-12-12 15:30Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329).
{
"affected": [],
"aliases": [
"CVE-2022-42328"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-07T01:15:00Z",
"severity": "MODERATE"
},
"details": "Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329).",
"id": "GHSA-7mxg-cx88-pj6r",
"modified": "2022-12-12T15:30:31Z",
"published": "2022-12-07T03:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42328"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-424.txt"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/12/08/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/12/08/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/12/09/2"
}
],
"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-7PQQ-RHF6-G42W
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-05-24 17:28In SurfaceFlinger, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the graphics server with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-150225569
{
"affected": [],
"aliases": [
"CVE-2020-0357"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-17T21:15:00Z",
"severity": "HIGH"
},
"details": "In SurfaceFlinger, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the graphics server with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-150225569",
"id": "GHSA-7pqq-rhf6-g42w",
"modified": "2022-05-24T17:28:44Z",
"published": "2022-05-24T17:28:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0357"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/android-11"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7PWM-MQQH-JMMQ
Vulnerability from github – Published: 2024-08-22 06:30 – Updated: 2024-08-22 21:31In the Linux kernel, the following vulnerability has been resolved:
io_uring: add a schedule point in io_add_buffers()
Looping ~65535 times doing kmalloc() calls can trigger soft lockups, especially with DEBUG features (like KASAN).
[ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575] [ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O) [ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801 [ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98) [ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40 [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246 [ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001 [ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004 [ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380 [ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0 [ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000 [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0 [ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 253.544494] Call Trace: [ 253.544496] [ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143) [ 253.544505] __kernel_text_address (kernel/extable.c:78) [ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19) [ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27) [ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143) [ 253.544521] stack_trace_save (kernel/stacktrace.c:123) [ 253.544527] _kasankmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544531] ? __kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524) [ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?) [ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524) [ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546) [ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078) [ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441) [ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096) [ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096) [ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) [ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?) [ 253.544596] __io_queue_sqe (fs/io_uring.c:?) [ 253.544600] io_queue_sqe (fs/io_uring.c:7143) [ 253.544603] io_submit_sqe (fs/io_uring.c:?) [ 253.544608] io_submit_sqes (fs/io_uring.c:?) [ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-48937"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T04:15:17Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: add a schedule point in io_add_buffers()\n\nLooping ~65535 times doing kmalloc() calls can trigger soft lockups,\nespecially with DEBUG features (like KASAN).\n\n[ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]\n[ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)\n[ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801\n[ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)\n[ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb \u003c48\u003e c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40\n[ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246\n[ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001\n[ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a\n[ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004\n[ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380\n[ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0\n[ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000\n[ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0\n[ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 253.544494] Call Trace:\n[ 253.544496] \u003cTASK\u003e\n[ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143)\n[ 253.544505] __kernel_text_address (kernel/extable.c:78)\n[ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)\n[ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)\n[ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143)\n[ 253.544521] stack_trace_save (kernel/stacktrace.c:123)\n[ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)\n[ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)\n[ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)\n[ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)\n[ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?)\n[ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524)\n[ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)\n[ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n[ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n[ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)\n[ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)\n[ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441)\n[ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)\n[ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)\n[ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n[ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)\n[ 253.544596] __io_queue_sqe (fs/io_uring.c:?)\n[ 253.544600] io_queue_sqe (fs/io_uring.c:7143)\n[ 253.544603] io_submit_sqe (fs/io_uring.c:?)\n[ 253.544608] io_submit_sqes (fs/io_uring.c:?)\n[ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri\n---truncated---",
"id": "GHSA-7pwm-mqqh-jmmq",
"modified": "2024-08-22T21:31:29Z",
"published": "2024-08-22T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48937"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a93c6594613c3429b6f30136fff115c7f803af4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f3cc3c5bc43d03b5748ac4fb8d180084952c36a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c718ea4e7382e18957ed0e88a5f855e2122d9c00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f240762f88b4b1b58561939ffd44837759756477"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-7Q3F-XF6V-WV4W
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-18 15:30In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix taking invalid lock on wedge
If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat:
[] xe 0000:bf:00.0: [drm] device wedged, needs recovery
[] ------------[ cut here ]------------
[] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60
...
[] RIP: 0010:__mutex_lock+0x8a1/0xe60
[] mutex_lock_nested+0x1b/0x30
[] xe_guc_submit_wedge+0x80/0x2b0 [xe]
{
"affected": [],
"aliases": [
"CVE-2025-38353"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix taking invalid lock on wedge\n\nIf device wedges on e.g. GuC upload, the submission is not yet enabled\nand the state is not even initialized. Protect the wedge call so it does\nnothing in this case. It fixes the following splat:\n\n\t[] xe 0000:bf:00.0: [drm] device wedged, needs recovery\n\t[] ------------[ cut here ]------------\n\t[] DEBUG_LOCKS_WARN_ON(lock-\u003emagic != lock)\n\t[] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60\n\t...\n\t[] RIP: 0010:__mutex_lock+0x8a1/0xe60\n\t[] mutex_lock_nested+0x1b/0x30\n\t[] xe_guc_submit_wedge+0x80/0x2b0 [xe]",
"id": "GHSA-7q3f-xf6v-wv4w",
"modified": "2025-11-18T15:30:41Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38353"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e1981b16bb1bbe2fafa57ed439b45cb5b34e32d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20eec7018e132a023f84ccbdf56b6c5b73d3094f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6d81b2d7037ef36163ad16459ed3fd17cb1b596"
}
],
"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-7QV7-C4H7-RW9M
Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-04-08 18:34Sensitive data storage in improperly locked memory in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-27732"
],
"database_specific": {
"cwe_ids": [
"CWE-591",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T18:16:01Z",
"severity": "HIGH"
},
"details": "Sensitive data storage in improperly locked memory in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-7qv7-c4h7-rw9m",
"modified": "2025-04-08T18:34:52Z",
"published": "2025-04-08T18:34:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27732"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-27732"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7QVV-HM32-963P
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-11-04 21:30In the Linux kernel, the following vulnerability has been resolved:
usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler
Patch fixes the following critical issue caused by deadlock which has been detected during testing NCM class:
smp: csd: Detected non-responsive CSD lock (#1) on CPU#0 smp: csd: CSD lock (#1) unresponsive. .... RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0 RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002 RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0 Call Trace: do_raw_spin_lock+0xc0/0xd0 _raw_spin_lock_irqsave+0x95/0xa0 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci] usb_ep_queue+0x35/0x110 eth_start_xmit+0x220/0x3d0 [u_ether] ncm_tx_timeout+0x34/0x40 [usb_f_ncm] ? ncm_free_inst+0x50/0x50 [usb_f_ncm] __hrtimer_run_queues+0xac/0x440 hrtimer_run_softirq+0x8c/0xb0 __do_softirq+0xcf/0x428 asm_call_irq_on_stack+0x12/0x20 do_softirq_own_stack+0x61/0x70 irq_exit_rcu+0xc1/0xd0 sysvec_apic_timer_interrupt+0x52/0xb0 asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0010:do_raw_spin_trylock+0x18/0x40 RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000 _raw_spin_lock+0x3d/0x70 ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci] ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci] ? irq_thread+0xa0/0x1c0 irq_thread_fn+0x28/0x60 irq_thread+0x105/0x1c0 ? __kthread_parkme+0x42/0x90 ? irq_forced_thread_fn+0x90/0x90 ? wake_threads_waitq+0x30/0x30 ? irq_thread_check_affinity+0xe0/0xe0 kthread+0x12a/0x160 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30
The root cause of issue is spin_lock/spin_unlock instruction instead spin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler function.
{
"affected": [],
"aliases": [
"CVE-2021-47271"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler\n\nPatch fixes the following critical issue caused by deadlock which has been\ndetected during testing NCM class:\n\nsmp: csd: Detected non-responsive CSD lock (#1) on CPU#0\nsmp: csd: CSD lock (#1) unresponsive.\n....\nRIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0\nRSP: 0018:ffffbc494011cde0 EFLAGS: 00000002\nRAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0\nCall Trace:\n \u003cIRQ\u003e\n do_raw_spin_lock+0xc0/0xd0\n _raw_spin_lock_irqsave+0x95/0xa0\n cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]\n usb_ep_queue+0x35/0x110\n eth_start_xmit+0x220/0x3d0 [u_ether]\n ncm_tx_timeout+0x34/0x40 [usb_f_ncm]\n ? ncm_free_inst+0x50/0x50 [usb_f_ncm]\n __hrtimer_run_queues+0xac/0x440\n hrtimer_run_softirq+0x8c/0xb0\n __do_softirq+0xcf/0x428\n asm_call_irq_on_stack+0x12/0x20\n \u003c/IRQ\u003e\n do_softirq_own_stack+0x61/0x70\n irq_exit_rcu+0xc1/0xd0\n sysvec_apic_timer_interrupt+0x52/0xb0\n asm_sysvec_apic_timer_interrupt+0x12/0x20\nRIP: 0010:do_raw_spin_trylock+0x18/0x40\nRSP: 0018:ffffbc494138bda8 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000\n _raw_spin_lock+0x3d/0x70\n ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]\n ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]\n ? irq_thread+0xa0/0x1c0\n irq_thread_fn+0x28/0x60\n irq_thread+0x105/0x1c0\n ? __kthread_parkme+0x42/0x90\n ? irq_forced_thread_fn+0x90/0x90\n ? wake_threads_waitq+0x30/0x30\n ? irq_thread_check_affinity+0xe0/0xe0\n kthread+0x12a/0x160\n ? kthread_park+0x90/0x90\n ret_from_fork+0x22/0x30\n\nThe root cause of issue is spin_lock/spin_unlock instruction instead\nspin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler\nfunction.",
"id": "GHSA-7qvv-hm32-963p",
"modified": "2024-11-04T21:30:26Z",
"published": "2024-05-21T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47271"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9aecef198faae3240921b707bc09b602e966fce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae746b6f4ce619cf4032fd798a232b010907a397"
}
],
"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-7QW8-847F-PGGM
Vulnerability from github – Published: 2021-05-10 19:35 – Updated: 2023-02-14 17:41A deadlock vulnerability was found in github.com/containers/storage in versions before 1.28.1. When a container image is processed, each layer is unpacked using tar. If one of those layers is not a valid tar archive this causes an error leading to an unexpected situation where the code indefinitely waits for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a malicious image, which when downloaded and stored by an application using containers/storage, would then cause a deadlock leading to a Denial of Service (DoS).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/containers/storage"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.28.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20291"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-04T19:15:55Z",
"nvd_published_at": "2021-04-01T18:15:00Z",
"severity": "MODERATE"
},
"details": "A deadlock vulnerability was found in `github.com/containers/storage` in versions before 1.28.1. When a container image is processed, each layer is unpacked using `tar`. If one of those layers is not a valid `tar` archive this causes an error leading to an unexpected situation where the code indefinitely waits for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a malicious image, which when downloaded and stored by an application using containers/storage, would then cause a deadlock leading to a Denial of Service (DoS).",
"id": "GHSA-7qw8-847f-pggm",
"modified": "2023-02-14T17:41:32Z",
"published": "2021-05-10T19:35:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20291"
},
{
"type": "WEB",
"url": "https://github.com/containers/storage/pull/860"
},
{
"type": "WEB",
"url": "https://github.com/containers/storage/commit/306fcabc964470e4b3b87a43a8f6b7d698209ee1"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1939485"
},
{
"type": "PACKAGE",
"url": "https://github.com/containers/storage"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/R5D7XL7FL24TWFMGQ3K2S72EOUSLZMKL"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SPYOHNG2Q7DCAQZMGYLMENLKALGDLG3X"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WX24EITRXVHDM5M223BVTJA2ODF2FSHI"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZNMB7O2UIXE34PGSCSOULGHPX5LIJBMM"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2021-0100"
},
{
"type": "WEB",
"url": "https://unit42.paloaltonetworks.com/cve-2021-20291"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Locking in github.com/containers/storage"
}
GHSA-7RCP-78XX-6FQM
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 21:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix possible deadlock in rfcomm_sk_state_change
syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow:
rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock()
rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk)
This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes.
{
"affected": [],
"aliases": [
"CVE-2023-53016"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix possible deadlock in rfcomm_sk_state_change\n\nsyzbot reports a possible deadlock in rfcomm_sk_state_change [1].\nWhile rfcomm_sock_connect acquires the sk lock and waits for\nthe rfcomm lock, rfcomm_sock_release could have the rfcomm\nlock and hit a deadlock for acquiring the sk lock.\nHere\u0027s a simplified flow:\n\nrfcomm_sock_connect:\n lock_sock(sk)\n rfcomm_dlc_open:\n rfcomm_lock()\n\nrfcomm_sock_release:\n rfcomm_sock_shutdown:\n rfcomm_lock()\n __rfcomm_dlc_close:\n rfcomm_k_state_change:\n\t lock_sock(sk)\n\nThis patch drops the sk lock before calling rfcomm_dlc_open to\navoid the possible deadlock and holds sk\u0027s reference count to\nprevent use-after-free after rfcomm_dlc_open completes.",
"id": "GHSA-7rcp-78xx-6fqm",
"modified": "2025-04-15T21:31:29Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53016"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17511bd84871f4a6106cb335616e086880313f3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d80d57ffcb55488f0ec0b77928d4f82d16b6a90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98aec50ff7f60cc6f2d6a4396b475c547e58b04d"
}
],
"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.