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.
721 vulnerabilities reference this CWE, most recent first.
GHSA-8QQ6-88XP-8GHP
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 00:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix deadlock in tc route query code
Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways:
-
RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is.
-
Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as "best effort" check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'.
-
Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.
[0]:
[ 164.599612] ====================================================== [ 164.600142] WARNING: possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021] ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.604459] which lock already depends on the new lock.
[ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [ 164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] _syssendmsg+0x1d0/0x1e0 [ 164.614934] _sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53591"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlock in tc route query code\n\nCited commit causes ABBA deadlock[0] when peer flows are created while\nholding the devcom rw semaphore. Due to peer flows offload implementation\nthe lock is taken much higher up the call chain and there is no obvious way\nto easily fix the deadlock. Instead, since tc route query code needs the\npeer eswitch structure only to perform a lookup in xarray and doesn\u0027t\nperform any sleeping operations with it, refactor the code for lockless\nexecution in following ways:\n\n- RCUify the devcom \u0027data\u0027 pointer. When resetting the pointer\nsynchronously wait for RCU grace period before returning. This is fine\nsince devcom is currently only used for synchronization of\npairing/unpairing of eswitches which is rare and already expensive as-is.\n\n- Wrap all usages of \u0027paired\u0027 boolean in {READ|WRITE}_ONCE(). The flag has\nalready been used in some unlocked contexts without proper\nannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn\u0027t\nan issue since all relevant code paths checked it again after obtaining the\ndevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as\n\"best effort\" check to return NULL when devcom is being unpaired. Note that\nwhile RCU read lock doesn\u0027t prevent the unpaired flag from being changed\nconcurrently it still guarantees that reader can continue to use \u0027data\u0027.\n\n- Refactor mlx5e_tc_query_route_vport() function to use new\nmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.\n\n[0]:\n\n[ 164.599612] ======================================================\n[ 164.600142] WARNING: possible circular locking dependency detected\n[ 164.600667] 6.3.0-rc3+ #1 Not tainted\n[ 164.601021] ------------------------------------------------------\n[ 164.601557] handler1/3456 is trying to acquire lock:\n[ 164.601998] ffff88811f1714b0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[ 164.603078]\n but task is already holding lock:\n[ 164.603617] ffff88810137fc98 (\u0026comp-\u003esem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[ 164.604459]\n which lock already depends on the new lock.\n\n[ 164.605190]\n the existing dependency chain (in reverse order) is:\n[ 164.605848]\n -\u003e #1 (\u0026comp-\u003esem){++++}-{3:3}:\n[ 164.606380] down_read+0x39/0x50\n[ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]\n[ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]\n[ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]\n[ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]\n[ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]\n[ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]\n[ 164.610741] tc_setup_cb_add+0xd4/0x200\n[ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]\n[ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]\n[ 164.612116] tc_new_tfilter+0x3fc/0xd20\n[ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0\n[ 164.612936] netlink_rcv_skb+0x54/0x100\n[ 164.613339] netlink_unicast+0x190/0x250\n[ 164.613746] netlink_sendmsg+0x245/0x4a0\n[ 164.614150] sock_sendmsg+0x38/0x60\n[ 164.614522] ____sys_sendmsg+0x1d0/0x1e0\n[ 164.614934] ___sys_sendmsg+0x80/0xc0\n[ 164.615320] __sys_sendmsg+0x51/0x90\n[ 164.615701] do_syscall_64+0x3d/0x90\n[ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 164.616568]\n -\u003e #0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}:\n[ 164.617210] __lock_acquire+0x159e/0x26e0\n[ 164.617638] lock_acquire+0xc2/0x2a0\n[ 164.618018] __mutex_lock+0x92/0xcd0\n[ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[ 164.618943] post_process_attr+0x153/0x2d0 [\n---truncated---",
"id": "GHSA-8qq6-88xp-8ghp",
"modified": "2026-02-10T00:30:28Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/362063df6ceec80b0b6798b61ae03504dcc125a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/691c041bf20899fc13c793f92ba61ab660fa3a30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69966bce28da6aadccfd968b75d128a79da32d17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7236e420a7d8082b1df4b3e05c739dd2642a662"
}
],
"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-8VM6-JVF8-6W38
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing locking around retry adding new subreqs
Fix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take the appropriate lock when adding extra subrequests into stream->subrequests.
{
"affected": [],
"aliases": [
"CVE-2026-64068"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:47Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing locking around retry adding new subreqs\n\nFix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take\nthe appropriate lock when adding extra subrequests into\nstream-\u003esubrequests.",
"id": "GHSA-8vm6-jvf8-6w38",
"modified": "2026-07-20T15:31:58Z",
"published": "2026-07-19T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64068"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/393f3f0d7353a94b1e0bc4ca89c683fe983e5fd2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cce18c263e9623872327ba3c956012f73c1179cc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8VV8-FMP2-X4C4
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-12-09 15:31In the Linux kernel, the following vulnerability has been resolved:
tpm: Lock TPM chip in tpm_pm_suspend() first
Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour.
Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.
{
"affected": [],
"aliases": [
"CVE-2024-53085"
],
"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\ntpm: Lock TPM chip in tpm_pm_suspend() first\n\nSetting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy\naccording, as this leaves window for tpm_hwrng_read() to be called while\nthe operation is in progress. The recent bug report gives also evidence of\nthis behaviour.\n\nAadress this by locking the TPM chip before checking any chip-\u003eflags both\nin tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED\ncheck inside tpm_get_random() so that it will be always checked only when\nthe lock is reserved.",
"id": "GHSA-8vv8-fmp2-x4c4",
"modified": "2024-12-09T15:31:33Z",
"published": "2024-11-19T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53085"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9265fed6db601ee2ec47577815387458ef4f047a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc203fe416abdd1c29da594565a7c3c4e979488e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfaf83501a0cbb104499c5b0892ee5ebde4e967f"
}
],
"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-8W9J-8C65-FRH3
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2026-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Don't call mmput from MMU notifier callback
If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace.
The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking.
The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work.
If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child.
The backtrace of hung task:
INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu]
(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
{
"affected": [],
"aliases": [
"CVE-2025-38520"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T11:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Don\u0027t call mmput from MMU notifier callback\n\nIf the process is exiting, the mmput inside mmu notifier callback from\ncompactd or fork or numa balancing could release the last reference\nof mm struct to call exit_mmap and free_pgtable, this triggers deadlock\nwith below backtrace.\n\nThe deadlock will leak kfd process as mmu notifier release is not called\nand cause VRAM leaking.\n\nThe fix is to take mm reference mmget_non_zero when adding prange to the\ndeferred list to pair with mmput in deferred list work.\n\nIf prange split and add into pchild list, the pchild work_item.mm is not\nused, so remove the mm parameter from svm_range_unmap_split and\nsvm_range_add_child.\n\nThe backtrace of hung task:\n\n INFO: task python:348105 blocked for more than 64512 seconds.\n Call Trace:\n __schedule+0x1c3/0x550\n schedule+0x46/0xb0\n rwsem_down_write_slowpath+0x24b/0x4c0\n unlink_anon_vmas+0xb1/0x1c0\n free_pgtables+0xa9/0x130\n exit_mmap+0xbc/0x1a0\n mmput+0x5a/0x140\n svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]\n mn_itree_invalidate+0x72/0xc0\n __mmu_notifier_invalidate_range_start+0x48/0x60\n try_to_unmap_one+0x10fa/0x1400\n rmap_walk_anon+0x196/0x460\n try_to_unmap+0xbb/0x210\n migrate_page_unmap+0x54d/0x7e0\n migrate_pages_batch+0x1c3/0xae0\n migrate_pages_sync+0x98/0x240\n migrate_pages+0x25c/0x520\n compact_zone+0x29d/0x590\n compact_zone_order+0xb6/0xf0\n try_to_compact_pages+0xbe/0x220\n __alloc_pages_direct_compact+0x96/0x1a0\n __alloc_pages_slowpath+0x410/0x930\n __alloc_pages_nodemask+0x3a9/0x3e0\n do_huge_pmd_anonymous_page+0xd7/0x3e0\n __handle_mm_fault+0x5e3/0x5f0\n handle_mm_fault+0xf7/0x2e0\n hmm_vma_fault.isra.0+0x4d/0xa0\n walk_pmd_range.isra.0+0xa8/0x310\n walk_pud_range+0x167/0x240\n walk_pgd_range+0x55/0x100\n __walk_page_range+0x87/0x90\n walk_page_range+0xf6/0x160\n hmm_range_fault+0x4f/0x90\n amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]\n amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]\n init_user_pages+0xb1/0x2a0 [amdgpu]\n amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]\n kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]\n kfd_ioctl+0x29d/0x500 [amdgpu]\n\n(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)",
"id": "GHSA-8w9j-8c65-frh3",
"modified": "2026-01-07T18:30:19Z",
"published": "2025-08-16T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38520"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/145a56bd68f4bff098d59fbc7c263d20dfef4fc4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7eb0a25010a674c8fdfbece38353ef7be8c5834"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1bde9d48e09933c361521720f77a8072083c83a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf234231fcbc7d391e2135b9518613218cc5347f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e90ee15ce28c61f6d83a0511c3e02e2662478350"
},
{
"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-8WHV-9RRR-8P39
Vulnerability from github – Published: 2022-01-20 00:01 – Updated: 2022-01-27 00:03An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series and SRX Series allows an unauthenticated networked attacker to cause a flowprocessing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue can occur in a scenario where the SIP ALG is enabled and specific SIP messages are being processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R1-S2, 21.2R2; 21.3 versions prior to 21.3R1-S1, 21.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1.
{
"affected": [],
"aliases": [
"CVE-2022-22175"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-19T01:15:00Z",
"severity": "HIGH"
},
"details": "An Improper Locking vulnerability in the SIP ALG of Juniper Networks Junos OS on MX Series and SRX Series allows an unauthenticated networked attacker to cause a flowprocessing daemon (flowd) crash and thereby a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. This issue can occur in a scenario where the SIP ALG is enabled and specific SIP messages are being processed simultaneously. This issue affects: Juniper Networks Junos OS on MX Series and SRX Series 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R1-S2, 21.2R2; 21.3 versions prior to 21.3R1-S1, 21.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1.",
"id": "GHSA-8whv-9rrr-8p39",
"modified": "2022-01-27T00:03:42Z",
"published": "2022-01-20T00:01:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22175"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11281"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-92W6-8752-JF23
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36In priorLinearAllocation of C2AllocatorIon.cpp, there is a possible use-after-free due to improper locking. This could lead to local information disclosure in the media codec with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-152239213
{
"affected": [],
"aliases": [
"CVE-2020-27035"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "In priorLinearAllocation of C2AllocatorIon.cpp, there is a possible use-after-free due to improper locking. This could lead to local information disclosure in the media codec with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-152239213",
"id": "GHSA-92w6-8752-jf23",
"modified": "2022-05-24T17:36:30Z",
"published": "2022-05-24T17:36:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27035"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2020-12-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-934P-M4FH-22Q3
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
ext4: do not create EA inode under buffer lock
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers.
{
"affected": [],
"aliases": [
"CVE-2024-40972"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: do not create EA inode under buffer lock\n\next4_xattr_set_entry() creates new EA inodes while holding buffer lock\non the external xattr block. This is problematic as it nests all the\nallocation locking (which acquires locks on other buffers) under the\nbuffer lock. This can even deadlock when the filesystem is corrupted and\ne.g. quota file is setup to contain xattr block as data block. Move the\nallocation of EA inode out of ext4_xattr_set_entry() into the callers.",
"id": "GHSA-934p-m4fh-22q3",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40972"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-93XM-X65X-HGXH
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: Fix the potential deadlock
When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock.
Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here.
Process A Process B
process_scheduled_works()
pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock);
pdr_locate_service() mutex_lock(&pdr->list_lock);
pdr_get_domain_list()
pr_err("PDR: %s get domain list
txn wait failed: %d\n",
req->service_name,
ret);
Timeout error log due to deadlock:
" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 "
Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1]
{
"affected": [],
"aliases": [
"CVE-2025-22014"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pdr: Fix the potential deadlock\n\nWhen some client process A call pdr_add_lookup() to add the look up for\nthe service and does schedule locator work, later a process B got a new\nserver packet indicating locator is up and call pdr_locator_new_server()\nwhich eventually sets pdr-\u003elocator_init_complete to true which process A\nsees and takes list lock and queries domain list but it will timeout due\nto deadlock as the response will queued to the same qmi-\u003ewq and it is\nordered workqueue and process B is not able to complete new server\nrequest work due to deadlock on list lock.\n\nFix it by removing the unnecessary list iteration as the list iteration\nis already being done inside locator work, so avoid it here and just\ncall schedule_work() here.\n\n Process A Process B\n\n process_scheduled_works()\npdr_add_lookup() qmi_data_ready_work()\n process_scheduled_works() pdr_locator_new_server()\n pdr-\u003elocator_init_complete=true;\n pdr_locator_work()\n mutex_lock(\u0026pdr-\u003elist_lock);\n\n pdr_locate_service() mutex_lock(\u0026pdr-\u003elist_lock);\n\n pdr_get_domain_list()\n pr_err(\"PDR: %s get domain list\n txn wait failed: %d\\n\",\n req-\u003eservice_name,\n ret);\n\nTimeout error log due to deadlock:\n\n\"\n PDR: tms/servreg get domain list txn wait failed: -110\n PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110\n\"\n\nThanks to Bjorn and Johan for letting me know that this commit also fixes\nan audio regression when using the in-kernel pd-mapper as that makes it\neasier to hit this race. [1]",
"id": "GHSA-93xm-x65x-hgxh",
"modified": "2025-11-03T21:33:30Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22014"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02612f1e4c34d94d6c8ee75bf7d254ed697e22d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a566a79aca9851fae140536e0fc5b0853c90a90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2eeb03ad9f42dfece63051be2400af487ddb96d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/daba84612236de3ab39083e62c9e326a654ebd20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2bbfd50e95bc117360f0f59e629aa03d821ebd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4489260f5713c94e1966e5f20445bff262876f4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-94F3-Q8QM-3FQ6
Vulnerability from github – Published: 2022-05-02 03:19 – Updated: 2024-02-09 03:32The inotify_read function in the Linux kernel 2.6.27 to 2.6.27.13, 2.6.28 to 2.6.28.2, and 2.6.29-rc3 allows local users to cause a denial of service (OOPS) via a read with an invalid address to an inotify instance, which causes the device's event list mutex to be unlocked twice and prevents proper synchronization of a data structure for the inotify instance.
{
"affected": [],
"aliases": [
"CVE-2009-0935"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-03-18T02:00:00Z",
"severity": "MODERATE"
},
"details": "The inotify_read function in the Linux kernel 2.6.27 to 2.6.27.13, 2.6.28 to 2.6.28.2, and 2.6.29-rc3 allows local users to cause a denial of service (OOPS) via a read with an invalid address to an inotify instance, which causes the device\u0027s event list mutex to be unlocked twice and prevents proper synchronization of a data structure for the inotify instance.",
"id": "GHSA-94f3-q8qm-3fq6",
"modified": "2024-02-09T03:32:54Z",
"published": "2022-05-02T03:19:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0935"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=488935"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49331"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=123337123501681\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28.3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/06/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/18/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/03/19/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/33624"
}
],
"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-94MC-R26H-RWJ7
Vulnerability from github – Published: 2025-02-09 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity()
The following call-chain leads to enabling interrupts in a nested interrupt disabled section:
irq_set_vcpu_affinity() irq_get_desc_lock() raw_spin_lock_irqsave() <--- Disable interrupts its_irq_set_vcpu_affinity() guard(raw_spinlock_irq) <--- Enables interrupts when leaving the guard() irq_put_desc_unlock() <--- Warns because interrupts are enabled
This was broken in commit b97e8a2f7130, which replaced the original raw_spin_[un]lock() pair with guard(raw_spinlock_irq).
Fix the issue by using guard(raw_spinlock).
[ tglx: Massaged change log ]
{
"affected": [],
"aliases": [
"CVE-2024-57949"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-09T12:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Don\u0027t enable interrupts in its_irq_set_vcpu_affinity()\n\nThe following call-chain leads to enabling interrupts in a nested interrupt\ndisabled section:\n\nirq_set_vcpu_affinity()\n irq_get_desc_lock()\n raw_spin_lock_irqsave() \u003c--- Disable interrupts\n its_irq_set_vcpu_affinity()\n guard(raw_spinlock_irq) \u003c--- Enables interrupts when leaving the guard()\n irq_put_desc_unlock() \u003c--- Warns because interrupts are enabled\n\nThis was broken in commit b97e8a2f7130, which replaced the original\nraw_spin_[un]lock() pair with guard(raw_spinlock_irq).\n\nFix the issue by using guard(raw_spinlock).\n\n[ tglx: Massaged change log ]",
"id": "GHSA-94mc-r26h-rwj7",
"modified": "2025-11-03T21:32:35Z",
"published": "2025-02-09T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57949"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35cb2c6ce7da545f3b5cb1e6473ad7c3a6f08310"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c84ff2e788fce0099ee3e71a3ed258b1ca1a223"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93955a7788121ab5a0f7f27e988b2ed1135a4866"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7b0e89610dd45ac6cf0d6f99bfa9ccc787db344"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.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"
}
]
}
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.