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-FWR4-VX34-QHJP
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...
{
"affected": [],
"aliases": [
"CVE-2025-39843"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T16:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...",
"id": "GHSA-fwr4-vx34-qhjp",
"modified": "2026-05-12T15:31:09Z",
"published": "2025-09-22T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/243b705a90ed8449f561a271cf251fd2e939f3db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/522ffe298627cfe72539d72167c2e20e72b5e856"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/850470a8413a8a78e772c4f6bd9fe81ec6bd5b0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/994b03b9605d36d814c611385fbf90ca6db20aa8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb3240ffd243bfb8b1e9dc568d484ecf9fd660ab"
},
{
"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-FX99-8M8G-RFWX
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-12-17 09:31In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Lock XArray when getting entries for the VM
Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there.
v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.
{
"affected": [],
"aliases": [
"CVE-2024-53080"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Lock XArray when getting entries for the VM\n\nSimilar to commit cac075706f29 (\"drm/panthor: Fix race when converting\ngroup handle to group object\") we need to use the XArray\u0027s internal\nlocking when retrieving a vm pointer from there.\n\nv2: Removed part of the patch that was trying to protect fetching\nthe heap pointer from XArray, as that operation is protected by\nthe @pool-\u003elock.",
"id": "GHSA-fx99-8m8g-rfwx",
"modified": "2024-12-17T09:31:05Z",
"published": "2024-11-19T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3342f066a8e1020a6f7d1fbd6b23bfdeda473eb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/444fa5b100e5c90550d6bccfe4476efb0391b3ca"
},
{
"type": "WEB",
"url": "https://project-zero.issues.chromium.org/issues/377500597"
}
],
"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-FXW3-5JMJ-82P9
Vulnerability from github – Published: 2025-10-22 18:30 – Updated: 2025-10-22 18:30In the Linux kernel, the following vulnerability has been resolved:
PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()
The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock:
sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0
Previously, pci_dev_lock() acquired the config space access lock before the device lock:
pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock
Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4).
Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path.
[bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
{
"affected": [],
"aliases": [
"CVE-2022-49434"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()\n\nThe sysfs sriov_numvfs_store() path acquires the device lock before the\nconfig space access lock:\n\n sriov_numvfs_store\n device_lock # A (1) acquire device lock\n sriov_configure\n vfio_pci_sriov_configure # (for example)\n vfio_pci_core_sriov_configure\n pci_disable_sriov\n sriov_disable\n pci_cfg_access_lock\n pci_wait_cfg # B (4) wait for dev-\u003eblock_cfg_access == 0\n\nPreviously, pci_dev_lock() acquired the config space access lock before the\ndevice lock:\n\n pci_dev_lock\n pci_cfg_access_lock\n dev-\u003eblock_cfg_access = 1 # B (2) set dev-\u003eblock_cfg_access = 1\n device_lock # A (3) wait for device lock\n\nAny path that uses pci_dev_lock(), e.g., pci_reset_function(), may\ndeadlock with sriov_numvfs_store() if the operations occur in the sequence\n(1) (2) (3) (4).\n\nAvoid the deadlock by reversing the order in pci_dev_lock() so it acquires\nthe device lock before the config space access lock, the same as the\nsriov_numvfs_store() path.\n\n[bhelgaas: combined and adapted commit log from Jay Zhou\u0027s independent\nsubsequent posting:\nhttps://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]",
"id": "GHSA-fxw3-5jmj-82p9",
"modified": "2025-10-22T18:30:31Z",
"published": "2025-10-22T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49434"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da9792920ab525b8a932aa9aeee34529ad7b83f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e"
}
],
"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-G29R-CH4V-Q6CX
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().
{
"affected": [],
"aliases": [
"CVE-2024-47143"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0027t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0027s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0027s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().",
"id": "GHSA-g29r-ch4v-q6cx",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7543c3e3b9b88212fcd0aaf5cab5588797bdc7de"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c1b4fea8d62285f5e1a8194889b39661608bd8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c212d91070beca0d03fef7bf988baf4ff4b3eee4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efe1b9bbf356357fdff0399af361133d6e3ba18e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2b95248a16c5186d1c658fc0aeb2f3bd95e5259"
},
{
"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-G2G9-6HGR-7F52
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio
Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem.
Warning will be produced if folio is not locked during unmap:
------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
{
"affected": [],
"aliases": [
"CVE-2025-21931"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio\n\nCommit b15c87263a69 (\"hwpoison, memory_hotplug: allow hwpoisoned pages to\nbe offlined) add page poison checks in do_migrate_range in order to make\noffline hwpoisoned page possible by introducing isolate_lru_page and\ntry_to_unmap for hwpoisoned page. However folio lock must be held before\ncalling try_to_unmap. Add it to fix this problem.\n\nWarning will be produced if folio is not locked during unmap:\n\n ------------[ cut here ]------------\n kernel BUG at ./include/linux/swapops.h:400!\n Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n Modules linked in:\n CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41\n Tainted: [W]=WARN\n Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : try_to_unmap_one+0xb08/0xd3c\n lr : try_to_unmap_one+0x3dc/0xd3c\n Call trace:\n try_to_unmap_one+0xb08/0xd3c (P)\n try_to_unmap_one+0x3dc/0xd3c (L)\n rmap_walk_anon+0xdc/0x1f8\n rmap_walk+0x3c/0x58\n try_to_unmap+0x88/0x90\n unmap_poisoned_folio+0x30/0xa8\n do_migrate_range+0x4a0/0x568\n offline_pages+0x5a4/0x670\n memory_block_action+0x17c/0x374\n memory_subsys_offline+0x3c/0x78\n device_offline+0xa4/0xd0\n state_store+0x8c/0xf0\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x44/0x54\n kernfs_fop_write_iter+0x118/0x1a8\n vfs_write+0x3a8/0x4bc\n ksys_write+0x6c/0xf8\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x44/0x100\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xd0\n el0t_64_sync_handler+0xc8/0xcc\n el0t_64_sync+0x198/0x19c\n Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)\n ---[ end trace 0000000000000000 ]---",
"id": "GHSA-g2g9-6hgr-7f52",
"modified": "2025-11-03T21:33:24Z",
"published": "2025-04-01T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21931"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3926b572fd073491bde13ec42ee08ac1b337bf4d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/576a2f4c437c19bec7d05d05b5990f178d2b0f40"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/629dfc6ba5431056701d4e44830f3409b989955a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93df6da64b004f75d307ed08d3f0f1020280d339"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af288a426c3e3552b62595c6138ec6371a17dbba"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G2QX-6GHW-67HM
Vulnerability from github – Published: 2022-02-15 00:33 – Updated: 2021-05-20 22:20An issue was discovered in Gitea in which an attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-gitea/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13246"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T22:20:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "An issue was discovered in Gitea in which an attacker can trigger a deadlock by initiating a transfer of a repository\u0027s ownership from one organization to another.",
"id": "GHSA-g2qx-6ghw-67hm",
"modified": "2021-05-20T22:20:34Z",
"published": "2022-02-15T00:33:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13246"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/issues/10549"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/11438"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=DmVgADSVS88"
}
],
"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"
}
],
"summary": "Denial of Service in Gitea"
}
GHSA-G477-G2GM-CJMF
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-03-07 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix deadlock during RTC update
There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.
Here is deadlock backtrace:
kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff __switch_to+0x1a8/0x2d4 __schedule+0x684/0xa98 schedule+0x48/0xc8 schedule_timeout+0x48/0x170 do_wait_for_common+0x108/0x1b0 wait_for_completion+0x44/0x60 __flush_work+0x39c/0x424 __cancel_work_sync+0xd8/0x208 cancel_delayed_work_sync+0x14/0x28 __ufshcd_wl_suspend+0x19c/0x480 ufshcd_wl_runtime_suspend+0x3c/0x1d4 scsi_runtime_suspend+0x78/0xc8 __rpm_callback+0x94/0x3e0 rpm_suspend+0x2d4/0x65c __pm_runtime_suspend+0x80/0x114 scsi_runtime_idle+0x38/0x6c rpm_idle+0x264/0x338 __pm_runtime_idle+0x80/0x110 ufshcd_rtc_work+0x128/0x1e4 process_one_work+0x26c/0x650 worker_thread+0x260/0x3d8 kthread+0x110/0x134 ret_from_fork+0x10/0x20
Skip updating RTC if RPM state is not RPM_ACTIVE.
{
"affected": [],
"aliases": [
"CVE-2024-44953"
],
"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\nscsi: ufs: core: Fix deadlock during RTC update\n\nThere is a deadlock when runtime suspend waits for the flush of RTC work,\nand the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.\n\nHere is deadlock backtrace:\n\nkworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367\nptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff\n\u003cffffffee5e71ddb0\u003e __switch_to+0x1a8/0x2d4\n\u003cffffffee5e71e604\u003e __schedule+0x684/0xa98\n\u003cffffffee5e71ea60\u003e schedule+0x48/0xc8\n\u003cffffffee5e725f78\u003e schedule_timeout+0x48/0x170\n\u003cffffffee5e71fb74\u003e do_wait_for_common+0x108/0x1b0\n\u003cffffffee5e71efe0\u003e wait_for_completion+0x44/0x60\n\u003cffffffee5d6de968\u003e __flush_work+0x39c/0x424\n\u003cffffffee5d6decc0\u003e __cancel_work_sync+0xd8/0x208\n\u003cffffffee5d6dee2c\u003e cancel_delayed_work_sync+0x14/0x28\n\u003cffffffee5e2551b8\u003e __ufshcd_wl_suspend+0x19c/0x480\n\u003cffffffee5e255fb8\u003e ufshcd_wl_runtime_suspend+0x3c/0x1d4\n\u003cffffffee5dffd80c\u003e scsi_runtime_suspend+0x78/0xc8\n\u003cffffffee5df93580\u003e __rpm_callback+0x94/0x3e0\n\u003cffffffee5df90b0c\u003e rpm_suspend+0x2d4/0x65c\n\u003cffffffee5df91448\u003e __pm_runtime_suspend+0x80/0x114\n\u003cffffffee5dffd95c\u003e scsi_runtime_idle+0x38/0x6c\n\u003cffffffee5df912f4\u003e rpm_idle+0x264/0x338\n\u003cffffffee5df90f14\u003e __pm_runtime_idle+0x80/0x110\n\u003cffffffee5e24ce44\u003e ufshcd_rtc_work+0x128/0x1e4\n\u003cffffffee5d6e3a40\u003e process_one_work+0x26c/0x650\n\u003cffffffee5d6e65c8\u003e worker_thread+0x260/0x3d8\n\u003cffffffee5d6edec8\u003e kthread+0x110/0x134\n\u003cffffffee5d616b18\u003e ret_from_fork+0x10/0x20\n\nSkip updating RTC if RPM state is not RPM_ACTIVE.",
"id": "GHSA-g477-g2gm-cjmf",
"modified": "2025-03-07T18:31:00Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44953"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3911af778f208e5f49d43ce739332b91e26bc48e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4921b76bc9421d3838e167f6a17ea3112d8fe62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f13f1858a28c68b7fc0d72c2008d5c1f80d2e8d5"
}
],
"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-G4HW-WV9W-W499
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-26 21:30In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: add lock to protect parameter num_rdy
Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.
kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&]
kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
{
"affected": [],
"aliases": [
"CVE-2023-53519"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report\u0026]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report\u0026]\n\nkworker/u16:3: [name:report\u0026]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:\u00a0 v4l2_m2m_buf_queue+0xd8/0x10c",
"id": "GHSA-g4hw-wv9w-w499",
"modified": "2026-01-26T21:30:30Z",
"published": "2025-10-01T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53519"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fc7f87725805197388ba749a1801df33000fa50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c71aa5f1cf961264690f2560503ea396b6e3c680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e52de26cb37459b16213438a2c82feb155dd3bbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef009fe2010ea2a3a7045ecb72729cf366e0967b"
}
],
"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-G55P-876W-V4VX
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-09-24 18:30In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x2b2/0x440 queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ? __schedule+0x369/0xb40 ? __pfx_irq_thread_fn+0x10/0x10 ? irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ? preempt_count_add+0x74/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
The current implementation uses a spinlock to protect event log workqueue and will lead to the Call Trace due to potential task rescheduling.
To address the locking issue, convert the spinlock to mutex, allowing the drain_workqueue() to be called in a safe mutex-locked context.
This change ensures proper synchronization when accessing the event log workqueue, preventing potential Call Trace and improving the overall robustness of the code.
{
"affected": [],
"aliases": [
"CVE-2024-35991"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Convert spinlock to mutex to lock evl workqueue\n\ndrain_workqueue() cannot be called safely in a spinlocked context due to\npossible task rescheduling. In the multi-task scenario, calling\nqueue_work() while drain_workqueue() will lead to a Call Trace as\npushing a work on a draining workqueue is not permitted in spinlocked\ncontext.\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0x7d/0x140\n ? __queue_work+0x2b2/0x440\n ? report_bug+0x1f8/0x200\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __queue_work+0x2b2/0x440\n queue_work_on+0x28/0x30\n idxd_misc_thread+0x303/0x5a0 [idxd]\n ? __schedule+0x369/0xb40\n ? __pfx_irq_thread_fn+0x10/0x10\n ? irq_thread+0xbc/0x1b0\n irq_thread_fn+0x21/0x70\n irq_thread+0x102/0x1b0\n ? preempt_count_add+0x74/0xa0\n ? __pfx_irq_thread_dtor+0x10/0x10\n ? __pfx_irq_thread+0x10/0x10\n kthread+0x103/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nThe current implementation uses a spinlock to protect event log workqueue\nand will lead to the Call Trace due to potential task rescheduling.\n\nTo address the locking issue, convert the spinlock to mutex, allowing\nthe drain_workqueue() to be called in a safe mutex-locked context.\n\nThis change ensures proper synchronization when accessing the event log\nworkqueue, preventing potential Call Trace and improving the overall\nrobustness of the code.",
"id": "GHSA-g55p-876w-v4vx",
"modified": "2025-09-24T18:30:22Z",
"published": "2024-05-20T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44"
}
],
"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-G5V6-WM74-GH57
Vulnerability from github – Published: 2026-07-02 15:32 – Updated: 2026-07-18 09:32In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order.
Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order.
The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.
{
"affected": [],
"aliases": [
"CVE-2026-53358"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-02T15:17:03Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: use chan timer to close channels in cleanup_listen()\n\nl2cap_chan_close() removes the channel from conn-\u003echan_l, which\nmust be done under conn-\u003elock. cleanup_listen() runs under the\nparent sk_lock, so acquiring conn-\u003elock would invert the\nestablished conn-\u003elock -\u003e chan-\u003elock -\u003e sk_lock order.\n\nInstead of calling l2cap_chan_close() directly, schedule\nl2cap_chan_timeout with delay 0 to close the channel\nasynchronously. The timeout handler already acquires conn-\u003elock\nand chan-\u003elock in the correct order.\n\nThe timer is only armed when chan-\u003econn is still set: if it is\nalready NULL, l2cap_conn_del() has already processed this channel\n(l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb),\nso there is nothing left to do. If l2cap_conn_del() races in\nafter the timer is armed, __clear_chan_timer() inside\nl2cap_chan_del() cancels it; if the timer has already fired, the\nhandler returns harmlessly because chan-\u003econn was cleared.",
"id": "GHSA-g5v6-wm74-gh57",
"modified": "2026-07-18T09:32:16Z",
"published": "2026-07-02T15:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53358"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3634cbdc2eb414b69ffa752ddbe5e0458518e321"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50dfec218808b148ab4247b1858031b7a32015c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7555fd885a0603f50e49a655850a1f2bd8a25398"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/859d3ace791ed878ae9ba5522c7844d960da8f88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89dec92041717b027216e110599e4f6d6c921b79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c8e620467a7b51562dbcefbd1f09f288d7d710d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1c100e2d61bd8c718b7d91fe3e050780a9bf72d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/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.