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-975C-W82Q-MXHV
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource.
However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that.
[pabeni@redhat.com: fixed commit message typo]
{
"affected": [],
"aliases": [
"CVE-2024-50210"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-08T06:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()\n\nIf get_clock_desc() succeeds, it calls fget() for the clockid\u0027s fd,\nand get the clk-\u003erwsem read lock, so the error path should release\nthe lock to make the lock balance and fput the clockid\u0027s fd to make\nthe refcount balance and release the fd related resource.\n\nHowever the below commit left the error path locked behind resulting in\nunbalanced locking. Check timespec64_valid_strict() before\nget_clock_desc() to fix it, because the \"ts\" is not changed\nafter that.\n\n[pabeni@redhat.com: fixed commit message typo]",
"id": "GHSA-975c-w82q-mxhv",
"modified": "2026-05-12T15:30:40Z",
"published": "2024-11-08T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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-9889-58R3-P8H2
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo
Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
{
"affected": [],
"aliases": [
"CVE-2025-37969"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T17:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo\n\nPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in\ncase pattern_len is equal to zero and the device FIFO is not empty.",
"id": "GHSA-9889-58r3-p8h2",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-9933-F4M5-7V96
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 21:31In the Linux kernel, the following vulnerability has been resolved:
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
This lockdep splat says it better than I could:
================================ WARNING: inconsistent lock state 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 _dosoftirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 irq event stamp: 7825 hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130 hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8 softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8 softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER#2); lock(_xmit_ETHER#2);
*** DEADLOCK ***
3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
Workqueue: events enetc_tx_onestep_tstamp Call trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11c
but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in process context, therefore with softirqs enabled (i.o.w., it can be interrupted by a softirq). If we hold the netif_tx_lock() when there is an interrupt, and the NET_TX softirq then gets scheduled, this will take the netif_tx_lock() a second time and deadlock the kernel.
To solve this, use netif_tx_lock_bh(), which blocks softirqs from running.
{
"affected": [],
"aliases": [
"CVE-2023-53022"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: avoid deadlock in enetc_tx_onestep_tstamp()\n\nThis lockdep splat says it better than I could:\n\n================================\nWARNING: inconsistent lock state\n6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\nkworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:\nffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0\n{IN-SOFTIRQ-W} state was registered at:\n _raw_spin_lock+0x5c/0xc0\n sch_direct_xmit+0x148/0x37c\n __dev_queue_xmit+0x528/0x111c\n ip6_finish_output2+0x5ec/0xb7c\n ip6_finish_output+0x240/0x3f0\n ip6_output+0x78/0x360\n ndisc_send_skb+0x33c/0x85c\n ndisc_send_rs+0x54/0x12c\n addrconf_rs_timer+0x154/0x260\n call_timer_fn+0xb8/0x3a0\n __run_timers.part.0+0x214/0x26c\n run_timer_softirq+0x3c/0x74\n __do_softirq+0x14c/0x5d8\n ____do_softirq+0x10/0x20\n call_on_irq_stack+0x2c/0x5c\n do_softirq_own_stack+0x1c/0x30\n __irq_exit_rcu+0x168/0x1a0\n irq_exit_rcu+0x10/0x40\n el1_interrupt+0x38/0x64\nirq event stamp: 7825\nhardirqs last enabled at (7825): [\u003cffffdf1f7200cae4\u003e] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [\u003cffffdf1f708105f0\u003e] __do_softirq+0x550/0x5d8\nsoftirqs last enabled at (7824): [\u003cffffdf1f7081050c\u003e] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [\u003cffffdf1f708166e0\u003e] ____do_softirq+0x10/0x20\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(_xmit_ETHER#2);\n \u003cInterrupt\u003e\n lock(_xmit_ETHER#2);\n\n *** DEADLOCK ***\n\n3 locks held by kworker/1:3/179:\n #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #1: ffff80000a0bbdc8 ((work_completion)(\u0026priv-\u003etx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #2: ffff3ec4036cd438 (\u0026dev-\u003etx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34\n\nWorkqueue: events enetc_tx_onestep_tstamp\nCall trace:\n print_usage_bug.part.0+0x208/0x22c\n mark_lock+0x7f0/0x8b0\n __lock_acquire+0x7c4/0x1ce0\n lock_acquire.part.0+0xe0/0x220\n lock_acquire+0x68/0x84\n _raw_spin_lock+0x5c/0xc0\n netif_freeze_queues+0x5c/0xc0\n netif_tx_lock+0x24/0x34\n enetc_tx_onestep_tstamp+0x20/0x100\n process_one_work+0x28c/0x6c0\n worker_thread+0x74/0x450\n kthread+0x118/0x11c\n\nbut I\u0027ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in\nprocess context, therefore with softirqs enabled (i.o.w., it can be\ninterrupted by a softirq). If we hold the netif_tx_lock() when there is\nan interrupt, and the NET_TX softirq then gets scheduled, this will take\nthe netif_tx_lock() a second time and deadlock the kernel.\n\nTo solve this, use netif_tx_lock_bh(), which blocks softirqs from\nrunning.",
"id": "GHSA-9933-f4m5-7v96",
"modified": "2025-04-15T21:31:30Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53022"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7"
}
],
"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-99GR-CW2X-89QP
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 15:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path
[Why] The evaluation for whether we need to use the DMUB HW lock isn't the same as whether we need to unlock which results in a hang when the fast path is used for ASIC without FAMS support.
[How] Store a flag that indicates whether we should use the lock and use that same flag to specify whether unlocking is needed.
{
"affected": [],
"aliases": [
"CVE-2026-43305"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path\n\n[Why]\nThe evaluation for whether we need to use the DMUB HW lock isn\u0027t the\nsame as whether we need to unlock which results in a hang when the\nfast path is used for ASIC without FAMS support.\n\n[How]\nStore a flag that indicates whether we should use the lock and use\nthat same flag to specify whether unlocking is needed.",
"id": "GHSA-99gr-cw2x-89qp",
"modified": "2026-05-15T15:30:33Z",
"published": "2026-05-08T15:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43305"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e387ad67efb100b645630ffbce7716786f52283"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af3303970da5ce5bfe6dffdd07f38f42aad603e0"
}
],
"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-99MJ-3X29-5MM3
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix deadlock while reading mqd from debugfs
An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce that part when reading by hand):
[ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-35795"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix deadlock while reading mqd from debugfs\n\nAn errant disk backup on my desktop got into debugfs and triggered the\nfollowing deadlock scenario in the amdgpu debugfs files. The machine\nalso hard-resets immediately after those lines are printed (although I\nwasn\u0027t able to reproduce that part when reading by hand):\n\n[ 1318.016074][ T1082] ======================================================\n[ 1318.016607][ T1082] WARNING: possible circular locking dependency detected\n[ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted\n[ 1318.017598][ T1082] ------------------------------------------------------\n[ 1318.018096][ T1082] tar/1082 is trying to acquire lock:\n[ 1318.018585][ T1082] ffff98c44175d6a0 (\u0026mm-\u003emmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80\n[ 1318.019084][ T1082]\n[ 1318.019084][ T1082] but task is already holding lock:\n[ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.020607][ T1082]\n[ 1318.020607][ T1082] which lock already depends on the new lock.\n[ 1318.020607][ T1082]\n[ 1318.022081][ T1082]\n[ 1318.022081][ T1082] the existing dependency chain (in reverse order) is:\n[ 1318.023083][ T1082]\n[ 1318.023083][ T1082] -\u003e #2 (reservation_ww_class_mutex){+.+.}-{3:3}:\n[ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0\n[ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90\n[ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330\n[ 1318.025683][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.026728][ T1082] kernel_init+0x15/0x1a0\n[ 1318.027242][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.028281][ T1082]\n[ 1318.028281][ T1082] -\u003e #1 (reservation_ww_class_acquire){+.+.}-{0:0}:\n[ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330\n[ 1318.029790][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.030722][ T1082] kernel_init+0x15/0x1a0\n[ 1318.031168][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.032011][ T1082]\n[ 1318.032011][ T1082] -\u003e #0 (\u0026mm-\u003emmap_lock){++++}-{3:3}:\n[ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680\n[ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0\n[ 1318.033487][ T1082] __might_fault+0x58/0x80\n[ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]\n[ 1318.034181][ T1082] full_proxy_read+0x55/0x80\n[ 1318.034487][ T1082] vfs_read+0xa7/0x360\n[ 1318.034788][ T1082] ksys_read+0x70/0xf0\n[ 1318.035085][ T1082] do_syscall_64+0x94/0x180\n[ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[ 1318.035664][ T1082]\n[ 1318.035664][ T1082] other info that might help us debug this:\n[ 1318.035664][ T1082]\n[ 1318.036487][ T1082] Chain exists of:\n[ 1318.036487][ T1082] \u0026mm-\u003emmap_lock --\u003e reservation_ww_class_acquire --\u003e reservation_ww_class_mutex\n[ 1318.036487][ T1082]\n[ 1318.037310][ T1082] Possible unsafe locking scenario:\n[ 1318.037310][ T1082]\n[ 1318.037838][ T1082] CPU0 CPU1\n[ 1318.038101][ T1082] ---- ----\n[ 1318.038350][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.038590][ T1082] lock(reservation_ww_class_acquire);\n[ 1318.038839][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.039083][ T1082] rlock(\u0026mm-\u003emmap_lock);\n[ 1318.039328][ T1082]\n[ 1318.039328][ T1082] *** DEADLOCK ***\n[ 1318.039328][ T1082]\n[ 1318.040029][ T1082] 1 lock held by tar/1082:\n[ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.040560][ T1082]\n[ 1318.040560][ T1082] stack backtrace:\n[\n---truncated---",
"id": "GHSA-99mj-3x29-5mm3",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35795"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/197f6d6987c55860f6eea1c93e4f800c59078874"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8db5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8678b1060ae2b75feb60b87e5b75e17374e3c1c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b03556da6e576c62664b6cd01809e4a09d53b5b"
}
],
"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-99VR-7HVG-69WF
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-39131"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.",
"id": "GHSA-99vr-7hvg-69wf",
"modified": "2022-12-07T18:30:28Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39131"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
}
],
"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-9C6C-JQH5-VQV4
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:49HP has identified a security vulnerability with some versions of Workstation BIOS (UEFI Firmware) where the runtime BIOS code could be tampered with if the TPM is disabled. This vulnerability relates to Workstations whose TPM is disabled by default.
{
"affected": [],
"aliases": [
"CVE-2019-6321"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-29T20:29:00Z",
"severity": "HIGH"
},
"details": "HP has identified a security vulnerability with some versions of Workstation BIOS (UEFI Firmware) where the runtime BIOS code could be tampered with if the TPM is disabled. This vulnerability relates to Workstations whose TPM is disabled by default.",
"id": "GHSA-9c6c-jqh5-vqv4",
"modified": "2024-04-04T00:49:32Z",
"published": "2022-05-24T16:46:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6321"
},
{
"type": "WEB",
"url": "https://support.hp.com/us-en/document/c06318199"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9CC8-5CMC-HCJ3
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30
{
"affected": [],
"aliases": [
"CVE-2022-49322"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix sleeping function called from invalid context on RT kernel\n\nWhen setting bootparams=\"trace_event=initcall:initcall_start tp_printk=1\" in the\ncmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the\natomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,\nthese locks are replaced with sleepable rt-spinlock, so the stack calltrace will\nbe triggered.\nFix it by raw_spin_lock_irqsave when PREEMPT_RT and \"trace_event=initcall:initcall_start\ntp_printk=1\" enabled.\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 2, expected: 0\n RCU nest depth: 0, expected: 0\n Preemption disabled at:\n [\u003cffffffff8992303e\u003e] try_to_wake_up+0x7e/0xba0\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x60/0x8c\n dump_stack+0x10/0x12\n __might_resched.cold+0x11d/0x155\n rt_spin_lock+0x40/0x70\n trace_event_buffer_commit+0x2fa/0x4c0\n ? map_vsyscall+0x93/0x93\n trace_event_raw_event_initcall_start+0xbe/0x110\n ? perf_trace_initcall_finish+0x210/0x210\n ? probe_sched_wakeup+0x34/0x40\n ? ttwu_do_wakeup+0xda/0x310\n ? trace_hardirqs_on+0x35/0x170\n ? map_vsyscall+0x93/0x93\n do_one_initcall+0x217/0x3c0\n ? trace_event_raw_event_initcall_level+0x170/0x170\n ? push_cpu_stop+0x400/0x400\n ? cblist_init_generic+0x241/0x290\n kernel_init_freeable+0x1ac/0x347\n ? _raw_spin_unlock_irq+0x65/0x80\n ? rest_init+0xf0/0xf0\n kernel_init+0x1e/0x150\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
"id": "GHSA-9cc8-5cmc-hcj3",
"modified": "2025-04-14T21:32:22Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49322"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1"
}
],
"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-9H35-HQFF-9V3W
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-29 06:31In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.
Lockdep splat:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock);
*** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2026-52946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:04Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u003e kill_fasync\n- send_sigurg() via tcp_check_urg -\u003e sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026tasklist_lock) in\n fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n read_lock(\u0026tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n \u0026dev-\u003eevent_lock --\u003e \u0026f_owner-\u003elock --\u003e tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(tasklist_lock);\n local_irq_disable();\n lock(\u0026dev-\u003eevent_lock);\n lock(\u0026f_owner-\u003elock);\n \u003cInterrupt\u003e\n lock(\u0026dev-\u003eevent_lock);\n\n*** DEADLOCK ***",
"id": "GHSA-9h35-hqff-9v3w",
"modified": "2026-06-29T06:31:48Z",
"published": "2026-06-24T18:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00633c4683828acd5256fa8d5163f440d74bbe71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bee417678f1135e35b25a37734db46aa94258d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a93e397abe850c49b6fa0e8cc827b5f634a8f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54626335ea4174ab2d9a183b511d825f6765e47b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897d6a7247739fb1528f98c575df4f2e5de7f994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5fa9e32fb6718f70c986ee14dd5d01b4846f331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfcc8e8d8a495bb34cae9e620adfb75fb13a3954"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9PPP-C797-FG56
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-15 15:32In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix af_unix iter deadlock
bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock():
WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0
but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(slock-AF_UNIX); lock(slock-AF_UNIX);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00
Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
{
"affected": [],
"aliases": [
"CVE-2026-53035"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix af_unix iter deadlock\n\nbpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast\npath and the iter prog attempts to update a sockmap. Which ends up spinning\nat sock_map_update_elem()\u0027s bh_lock_sock():\n\nWARNING: possible recursive locking detected\ntest_progs/1393 is trying to acquire lock:\nffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0\n\nbut task is already holding lock:\nffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(slock-AF_UNIX);\n lock(slock-AF_UNIX);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n4 locks held by test_progs/1393:\n #0: ffff88814b59c790 (\u0026p-\u003elock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0\n #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0\n #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0\n #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00\n\nCall Trace:\n dump_stack_lvl+0x5d/0x80\n print_deadlock_bug.cold+0xc0/0xce\n __lock_acquire+0x130f/0x2590\n lock_acquire+0x14e/0x2b0\n _raw_spin_lock+0x30/0x40\n sock_map_update_elem+0xdb/0x1f0\n bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4\n bpf_iter_run_prog+0x5b9/0xb00\n bpf_iter_unix_seq_show+0x1f7/0x2e0\n bpf_seq_read+0x42c/0x10d0\n vfs_read+0x171/0xb20\n ksys_read+0xff/0x200\n do_syscall_64+0x6b/0x3a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e",
"id": "GHSA-9ppp-c797-fg56",
"modified": "2026-07-15T15:32:45Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53035"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cef33b9813b78f227942572fb317afcd5c9ac94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d328dd695383224aa750ddee6b4ad40c0f8d205"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/527057ebe8076dfbcaef51195ff1b7508646be2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66d9fab4565eafe1afe7ba0581f79b76073b60fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87828b380956d4986f59f2c086e0b09b3e6cdaae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd3592129f24243713673a07225cf1f15a9bb835"
}
],
"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.