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.
733 vulnerabilities reference this CWE, most recent first.
GHSA-R5FX-27QQ-PWQG
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-08 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()
dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation.
However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function.
Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.
{
"affected": [],
"aliases": [
"CVE-2026-31756"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()\n\ndwc2_gadget_exit_clock_gating() internally calls call_gadget() macro,\nwhich expects hsotg-\u003elock to be held since it does spin_unlock/spin_lock\naround the gadget driver callback invocation.\n\nHowever, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating()\nwithout holding the lock. This leads to:\n - spin_unlock on a lock that is not held (undefined behavior)\n - The lock remaining held after dwc2_gadget_exit_clock_gating() returns,\n causing a deadlock when spin_lock_irqsave() is called later in the\n same function.\n\nFix this by acquiring hsotg-\u003elock before calling\ndwc2_gadget_exit_clock_gating() and releasing it afterwards, which\nsatisfies the locking requirement of the call_gadget() macro.",
"id": "GHSA-r5fx-27qq-pwqg",
"modified": "2026-05-08T18:31:25Z",
"published": "2026-05-01T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31756"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ed9d2dd9f29828c311db6ec4b8e0d34bfd6d6a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51b62286fc668c6eb74dee7624ec0beec3c5a0ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61937f686290494998236c680ce0836b8dd63a3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ffe31acb3b77a30ae34d01719a269881569fb7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bb4b5ed7f8c4f95cc556bdf042b0ba2fa13557a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/beab10429439e20708036a66fb0d97ffb79da6a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9fcca3e87463013d595c65c2189ffaa32ad3b50"
}
],
"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-R5HJ-8P6X-9RQ8
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: f_midi: f_midi_complete to call queue_work
When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock.
Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.
{
"affected": [],
"aliases": [
"CVE-2025-21859"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: f_midi: f_midi_complete to call queue_work\n\nWhen using USB MIDI, a lock is attempted to be acquired twice through a\nre-entrant call to f_midi_transmit, causing a deadlock.\n\nFix it by using queue_work() to schedule the inner f_midi_transmit() via\na high priority work queue from the completion handler.",
"id": "GHSA-r5hj-8p6x-9rq8",
"modified": "2026-05-12T15:30:51Z",
"published": "2025-03-12T12:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21859"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f10923404705a94891e612dff3b75e828a78368"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24a942610ee9bafb2692a456ae850c5b2e409b05"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ab37fcb42832cdd3e9d5e50653285ca84d6686f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/727dee0857946b85232526de4f5a957fe163e89a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8aa6b4be1f4efccbfc533e6ec8841d26e4fa8dba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b09957657d7767d164b3432af2129bd72947553c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/deeee3adb2c01eedab32c3b4519337689ad02e8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9fec6f42c45db2f62dc373fb1a10d2488c04e79"
},
{
"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-R64J-946X-G525
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-11-21 00:30In the Linux kernel, the following vulnerability has been resolved:
e1000: Move cancel_work_sync to avoid deadlock
Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL.
As reported by users and syzbot, a deadlock is possible in the following scenario:
CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task())
CPU 1: - process_one_work - e1000_reset_task - take RTNL
To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.
{
"affected": [],
"aliases": [
"CVE-2025-38114"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ne1000: Move cancel_work_sync to avoid deadlock\n\nPreviously, e1000_down called cancel_work_sync for the e1000 reset task\n(via e1000_down_and_stop), which takes RTNL.\n\nAs reported by users and syzbot, a deadlock is possible in the following\nscenario:\n\nCPU 0:\n - RTNL is held\n - e1000_close\n - e1000_down\n - cancel_work_sync (cancel / wait for e1000_reset_task())\n\nCPU 1:\n - process_one_work\n - e1000_reset_task\n - take RTNL\n\nTo remedy this, avoid calling cancel_work_sync from e1000_down\n(e1000_reset_task does nothing if the device is down anyway). Instead,\ncall cancel_work_sync for e1000_reset_task when the device is being\nremoved.",
"id": "GHSA-r64j-946x-g525",
"modified": "2025-11-21T00:30:20Z",
"published": "2025-07-03T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38114"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fd4438ddcc4958ed24662d5125114299e19bae4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4a8085ceefb7bbb12c2b71c55e71fc946c6929f"
}
],
"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-R6VX-43G9-HVQX
Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-23 21:30In the Linux kernel, the following vulnerability has been resolved:
debugobjects: Don't call fill_pool() in early boot hardirq context
When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was reported to the console.
During early boot, interrupts are enabled before the scheduler is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can fire and in the hard interrupt context handler attempt to fill the pool
This can lead to a deadlock when the interrupt occurred when the interrupt hits a region which holds a lock that is required to be taken in the allocation path.
Add a new can_fill_pool() helper and reorder the exception rule and forbid this scenario by excluding allocations from hard interrupt context.
{
"affected": [],
"aliases": [
"CVE-2026-53326"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T14:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndebugobjects: Don\u0027t call fill_pool() in early boot hardirq context\n\nWhen booting a debug PREEMPT_RT kernel on an ARM64 system, a \"inconsistent\n{HARDIRQ-ON-W} -\u003e {IN-HARDIRQ-W} usage\" lockdep warning message was\nreported to the console.\n\nDuring early boot, interrupts are enabled before the scheduler is\nenabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can\nfire and in the hard interrupt context handler attempt to fill the pool\n\nThis can lead to a deadlock when the interrupt occurred when the interrupt\nhits a region which holds a lock that is required to be taken in the\nallocation path.\n\nAdd a new can_fill_pool() helper and reorder the exception rule and forbid\nthis scenario by excluding allocations from hard interrupt context.",
"id": "GHSA-r6vx-43g9-hvqx",
"modified": "2026-07-23T21:30:35Z",
"published": "2026-07-01T15:35:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53326"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d046ae106255cba5eb83b23f78ee93f3620247d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27335c50014102e9077b784ebd314954286afcab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cc90ea0dd0fb1f8db577dcdc027fc46c06049f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44b8b03a9fb5c575548fc72c674653d6baba142a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d95f6b267f3d7fe54f42a3b224bb4a3d3990b41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bc71bdb1c1526c7f02a6adab324394ff1327b0a"
}
],
"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-R6XX-P5P2-8G36
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519217.
{
"affected": [],
"aliases": [
"CVE-2023-20746"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:14Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519217.",
"id": "GHSA-r6xx-p5p2-8g36",
"modified": "2024-04-04T04:35:40Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20746"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R7RX-Q42Q-VQ8V
Vulnerability from github – Published: 2024-08-26 12:31 – Updated: 2024-08-27 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double inode unlock for direct IO sync writes
If we do a direct IO sync write, at btrfs_sync_file(), and we need to skip inode logging or we get an error starting a transaction or an error when flushing delalloc, we end up unlocking the inode when we shouldn't under the 'out_release_extents' label, and then unlock it again at btrfs_direct_write().
Fix that by checking if we have to skip inode unlocking under that label.
{
"affected": [],
"aliases": [
"CVE-2024-43885"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-26T11:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix double inode unlock for direct IO sync writes\n\nIf we do a direct IO sync write, at btrfs_sync_file(), and we need to skip\ninode logging or we get an error starting a transaction or an error when\nflushing delalloc, we end up unlocking the inode when we shouldn\u0027t under\nthe \u0027out_release_extents\u0027 label, and then unlock it again at\nbtrfs_direct_write().\n\nFix that by checking if we have to skip inode unlocking under that label.",
"id": "GHSA-r7rx-q42q-vq8v",
"modified": "2024-08-27T15:32:43Z",
"published": "2024-08-26T12:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43885"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a607d22dea4f60438747705495ec4d0af2ec451"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ba27f14161fc20c4fc0051658a22ddd832eb0aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8bd4c9220416111500c275546c69c63d42185793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d924a0be2f218501588cf463d70f1c71afea06d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0391e92f9ab4fb3dbdeb139c967dcfa7ac4b115"
}
],
"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-R7XR-JH3W-26WW
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix held lock freed on hfsplus_fill_super()
hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning.
Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path.
The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available.
We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount:
=========================
WARNING: held lock freed!
7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted
-------------------------
mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!
ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0
2 locks held by mount/174:
#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40
#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0
stack backtrace:
CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x82/0xd0
debug_check_no_locks_freed+0x13a/0x180
kfree+0x16b/0x510
? hfsplus_fill_super+0xcb4/0x18a0
hfsplus_fill_super+0xcb4/0x18a0
? __pfx_hfsplus_fill_super+0x10/0x10
? srso_return_thunk+0x5/0x5f
? bdev_open+0x65f/0xc30
? srso_return_thunk+0x5/0x5f
? pointer+0x4ce/0xbf0
? trace_contention_end+0x11c/0x150
? __pfx_pointer+0x10/0x10
? srso_return_thunk+0x5/0x5f
? bdev_open+0x79b/0xc30
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? vsnprintf+0x6da/0x1270
? srso_return_thunk+0x5/0x5f
? __mutex_unlock_slowpath+0x157/0x740
? __pfx_vsnprintf+0x10/0x10
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? mark_held_locks+0x49/0x80
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? irqentry_exit+0x17b/0x5e0
? trace_irq_disable.constprop.0+0x116/0x150
? __pfx_hfsplus_fill_super+0x10/0x10
? __pfx_hfsplus_fill_super+0x10/0x10
get_tree_bdev_flags+0x302/0x580
? __pfx_get_tree_bdev_flags+0x10/0x10
? vfs_parse_fs_qstr+0x129/0x1a0
? __pfx_vfs_parse_fs_qstr+0x3/0x10
vfs_get_tree+0x89/0x320
fc_mount+0x10/0x1d0
path_mount+0x5c5/0x21c0
? __pfx_path_mount+0x10/0x10
? trace_irq_enable.constprop.0+0x116/0x150
? trace_irq_enable.constprop.0+0x116/0x150
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? kmem_cache_free+0x307/0x540
? user_path_at+0x51/0x60
? __x64_sys_mount+0x212/0x280
? srso_return_thunk+0x5/0x5f
__x64_sys_mount+0x212/0x280
? __pfx___x64_sys_mount+0x10/0x10
? srso_return_thunk+0x5/0x5f
? trace_irq_enable.constprop.0+0x116/0x150
? srso_return_thunk+0x5/0x5f
do_syscall_64+0x111/0x680
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ffacad55eae
Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8
RSP: 002b
---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-46299"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:48Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix held lock freed on hfsplus_fill_super()\n\nhfsplus_fill_super() calls hfs_find_init() to initialize a search\nstructure, which acquires tree-\u003etree_lock. If the subsequent call to\nhfsplus_cat_build_key() fails, the function jumps to the out_put_root\nerror label without releasing the lock. The later cleanup path then\nfrees the tree data structure with the lock still held, triggering a\nheld lock freed warning.\n\nFix this by adding the missing hfs_find_exit(\u0026fd) call before jumping\nto the out_put_root error label. This ensures that tree-\u003etree_lock is\nproperly released on the error path.\n\nThe bug was originally detected on v6.13-rc1 using an experimental\nstatic analysis tool we are developing, and we have verified that the\nissue persists in the latest mainline kernel. The tool is specifically\ndesigned to detect memory management issues. It is currently under active\ndevelopment and not yet publicly available.\n\nWe confirmed the bug by runtime testing under QEMU with x86_64 defconfig,\nlockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we\nused GDB to dynamically shrink the max_unistr_len parameter to 1 before\nhfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally\nreturn -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and\nexercises the faulty error path. The following warning was observed\nduring mount:\n\n\t=========================\n\tWARNING: held lock freed!\n\t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted\n\t-------------------------\n\tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!\n\tffff888103f920b0 (\u0026tree-\u003etree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0\n\t2 locks held by mount/174:\n\t#0: ffff888103f960e0 (\u0026type-\u003es_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40\n\t#1: ffff888103f920b0 (\u0026tree-\u003etree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0\n\n\tstack backtrace:\n\tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)\n\tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n\tCall Trace:\n\t\u003cTASK\u003e\n\tdump_stack_lvl+0x82/0xd0\n\tdebug_check_no_locks_freed+0x13a/0x180\n\tkfree+0x16b/0x510\n\t? hfsplus_fill_super+0xcb4/0x18a0\n\thfsplus_fill_super+0xcb4/0x18a0\n\t? __pfx_hfsplus_fill_super+0x10/0x10\n\t? srso_return_thunk+0x5/0x5f\n\t? bdev_open+0x65f/0xc30\n\t? srso_return_thunk+0x5/0x5f\n\t? pointer+0x4ce/0xbf0\n\t? trace_contention_end+0x11c/0x150\n\t? __pfx_pointer+0x10/0x10\n\t? srso_return_thunk+0x5/0x5f\n\t? bdev_open+0x79b/0xc30\n\t? srso_return_thunk+0x5/0x5f\n\t? srso_return_thunk+0x5/0x5f\n\t? vsnprintf+0x6da/0x1270\n\t? srso_return_thunk+0x5/0x5f\n\t? __mutex_unlock_slowpath+0x157/0x740\n\t? __pfx_vsnprintf+0x10/0x10\n\t? srso_return_thunk+0x5/0x5f\n\t? srso_return_thunk+0x5/0x5f\n\t? mark_held_locks+0x49/0x80\n\t? srso_return_thunk+0x5/0x5f\n\t? srso_return_thunk+0x5/0x5f\n\t? irqentry_exit+0x17b/0x5e0\n\t? trace_irq_disable.constprop.0+0x116/0x150\n\t? __pfx_hfsplus_fill_super+0x10/0x10\n\t? __pfx_hfsplus_fill_super+0x10/0x10\n\tget_tree_bdev_flags+0x302/0x580\n\t? __pfx_get_tree_bdev_flags+0x10/0x10\n\t? vfs_parse_fs_qstr+0x129/0x1a0\n\t? __pfx_vfs_parse_fs_qstr+0x3/0x10\n\tvfs_get_tree+0x89/0x320\n\tfc_mount+0x10/0x1d0\n\tpath_mount+0x5c5/0x21c0\n\t? __pfx_path_mount+0x10/0x10\n\t? trace_irq_enable.constprop.0+0x116/0x150\n\t? trace_irq_enable.constprop.0+0x116/0x150\n\t? srso_return_thunk+0x5/0x5f\n\t? srso_return_thunk+0x5/0x5f\n\t? kmem_cache_free+0x307/0x540\n\t? user_path_at+0x51/0x60\n\t? __x64_sys_mount+0x212/0x280\n\t? srso_return_thunk+0x5/0x5f\n\t__x64_sys_mount+0x212/0x280\n\t? __pfx___x64_sys_mount+0x10/0x10\n\t? srso_return_thunk+0x5/0x5f\n\t? trace_irq_enable.constprop.0+0x116/0x150\n\t? srso_return_thunk+0x5/0x5f\n\tdo_syscall_64+0x111/0x680\n\tentry_SYSCALL_64_after_hwframe+0x77/0x7f\n\tRIP: 0033:0x7ffacad55eae\n\tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8\n\tRSP: 002b\n---truncated---",
"id": "GHSA-r7xr-jh3w-26ww",
"modified": "2026-06-19T15:33:14Z",
"published": "2026-06-08T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46299"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/041acda6d9f96006703466449c10c9a69590c8b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ca80e3012c8be85b4f8d0d20eac8d3b17ff257e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6499c9c8ec437a369e7e221dad91f6122b50759d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90c500e4fd83fa33c09bc7ee23b6d9cc487ac733"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c554ddc87af4d4e4be42f8aed1baec9e1c7588e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d309d3308de658d87c42d97e044c89a226327526"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e890656accee4c26d932ea388eb8936a6e22184d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R7XW-J6RQ-F93P
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921s: fix potential hung tasks during chip recovery
During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device.
This patch prevents the execution of stat_worker during the chip recovery.
{
"affected": [],
"aliases": [
"CVE-2024-40977"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921s: fix potential hung tasks during chip recovery\n\nDuring chip recovery (e.g. chip reset), there is a possible situation that\nkernel worker reset_work is holding the lock and waiting for kernel thread\nstat_worker to be parked, while stat_worker is waiting for the release of\nthe same lock.\nIt causes a deadlock resulting in the dumping of hung tasks messages and\npossible rebooting of the device.\n\nThis patch prevents the execution of stat_worker during the chip recovery.",
"id": "GHSA-r7xw-j6rq-f93p",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40977"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366"
},
{
"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-R8HV-J9G9-64G6
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-11 18:31In the Linux kernel, the following vulnerability has been resolved:
cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
A chain of commits going back to v7.0 reworked rmdir to satisfy the controller invariant that a subsystem's ->css_offline() must not run while tasks are still doing kernel-side work in the cgroup.
[1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") [4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition") [5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context")
[1] moved task cset unlink from do_exit() to finish_task_switch() so a task's cset link drops only after the task has fully stopped scheduling. That made tasks past exit_signals() linger on cset->tasks until their final context switch, which led to a series of problems as what userspace expected to see after rmdir diverged from what the kernel needs to wait for. [2]-[5] tried to bridge that divergence: [2] filtered the exiting tasks from cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4] fixed the wait's condition; [5] made nr_dying_subsys_* visible synchronously.
The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g. host PID 1 systemd reaping orphan pids that were re-parented to it during the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those pids to free, the pids can't free because PID 1 is the reaper and it's stuck in rmdir, and the system A-A deadlocks. No internal lock ordering breaks this; the wait itself is the bug.
The css killing side that drove the original reorder, however, can be made cleanly asynchronous: ->css_offline() is already async, run from css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to make that chain start only after all tasks have left the cgroup. rmdir's user-visible side then returns as soon as cgroup.procs and friends are empty, while ->css_offline() still runs only after the cgroup is fully drained.
Verified by the original reproducer (pidns teardown + zombie reaper, runs under vng) which hangs vanilla and succeeds here, and by per-commit deterministic repros for [2], [3], [4], [5] with a boot parameter that widens the post-exit_signals() window so each state is reliably reachable. Some stress tests on top of that.
cgroup_apply_control_disable() has the same shape of pre-existing race: when a controller is disabled via subtree_control, kill_css() ran synchronously while tasks past exit_signals() could still be linked to the cgroup's csets, and ->css_offline() could fire before they drained. This patch preserves the existing synchronous behavior at that call site (kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch will defer kill_css_finish() there using a per-css trigger.
This seems like the right approach and I don't see problems with it. The changes are somewhat invasive but not excessively so, so backporting to -stable should be okay. If something does turn out to be wrong, the fallback is to revert the entire chain ([1]-[5]) and rework in the development branch instead.
v2: Pin cgrp across the deferred destroy work with explicit cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1 wasn't actually broken (ordered cgroup_offline_wq + queue_work order in cgroup_task_dead() saved it) but the explicit ref removes the dependency on those non-obvious invariants. Also note the pre-existing cgroup_apply_control_disable() race in the description; a follow-up will defer kill_css_finish() there.
{
"affected": [],
"aliases": [
"CVE-2026-46223"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated\n\nA chain of commits going back to v7.0 reworked rmdir to satisfy the\ncontroller invariant that a subsystem\u0027s -\u003ecss_offline() must not run while\ntasks are still doing kernel-side work in the cgroup.\n\n[1] d245698d727a (\"cgroup: Defer task cgroup unlink until after the task is done switching out\")\n[2] a72f73c4dd9b (\"cgroup: Don\u0027t expose dead tasks in cgroup\")\n[3] 1b164b876c36 (\"cgroup: Wait for dying tasks to leave on rmdir\")\n[4] 4c56a8ac6869 (\"cgroup: Fix cgroup_drain_dying() testing the wrong condition\")\n[5] 13e786b64bd3 (\"cgroup: Increment nr_dying_subsys_* from rmdir context\")\n\n[1] moved task cset unlink from do_exit() to finish_task_switch() so a\ntask\u0027s cset link drops only after the task has fully stopped scheduling.\nThat made tasks past exit_signals() linger on cset-\u003etasks until their final\ncontext switch, which led to a series of problems as what userspace expected\nto see after rmdir diverged from what the kernel needs to wait for. [2]-[5]\ntried to bridge that divergence: [2] filtered the exiting tasks from\ncgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]\nfixed the wait\u0027s condition; [5] made nr_dying_subsys_* visible\nsynchronously.\n\nThe cgroup_drain_dying() wait in [3] turned out to be a dead end. When the\nrmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.\nhost PID 1 systemd reaping orphan pids that were re-parented to it during\nthe same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those\npids to free, the pids can\u0027t free because PID 1 is the reaper and it\u0027s stuck\nin rmdir, and the system A-A deadlocks. No internal lock ordering breaks\nthis; the wait itself is the bug.\n\nThe css killing side that drove the original reorder, however, can be made\ncleanly asynchronous: -\u003ecss_offline() is already async, run from\ncss_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to\nmake that chain start only after all tasks have left the cgroup. rmdir\u0027s\nuser-visible side then returns as soon as cgroup.procs and friends are\nempty, while -\u003ecss_offline() still runs only after the cgroup is fully\ndrained.\n\nVerified by the original reproducer (pidns teardown + zombie reaper, runs\nunder vng) which hangs vanilla and succeeds here, and by per-commit\ndeterministic repros for [2], [3], [4], [5] with a boot parameter that\nwidens the post-exit_signals() window so each state is reliably reachable.\nSome stress tests on top of that.\n\ncgroup_apply_control_disable() has the same shape of pre-existing race:\nwhen a controller is disabled via subtree_control, kill_css() ran\nsynchronously while tasks past exit_signals() could still be linked to\nthe cgroup\u0027s csets, and -\u003ecss_offline() could fire before they drained.\nThis patch preserves the existing synchronous behavior at that call site\n(kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch\nwill defer kill_css_finish() there using a per-css trigger.\n\nThis seems like the right approach and I don\u0027t see problems with it. The\nchanges are somewhat invasive but not excessively so, so backporting to\n-stable should be okay. If something does turn out to be wrong, the fallback\nis to revert the entire chain ([1]-[5]) and rework in the development branch\ninstead.\n\nv2: Pin cgrp across the deferred destroy work with explicit\n cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1\n wasn\u0027t actually broken (ordered cgroup_offline_wq + queue_work order\n in cgroup_task_dead() saved it) but the explicit ref removes the\n dependency on those non-obvious invariants. Also note the\n pre-existing cgroup_apply_control_disable() race in the description;\n a follow-up will defer kill_css_finish() there.",
"id": "GHSA-r8hv-j9g9-64g6",
"modified": "2026-06-11T18:31:31Z",
"published": "2026-05-28T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46223"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33fa2e6b1507a0a377a151a8826438bedad1d0b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93618edf753838a727dbff63c7c291dee22d656b"
}
],
"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-R95C-H52X-X56P
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-04 15:30In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix deadlock triggered by cancel_delayed_work_syn()
The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53233"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix deadlock triggered by cancel_delayed_work_syn()\n\nThe following LOCKDEP was detected:\n\t\tWorkqueue: events smc_lgr_free_work [smc]\n\t\tWARNING: possible circular locking dependency detected\n\t\t6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted\n\t\t------------------------------------------------------\n\t\tkworker/3:0/176251 is trying to acquire lock:\n\t\t00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},\n\t\t\tat: __flush_workqueue+0x7a/0x4f0\n\t\tbut task is already holding lock:\n\t\t0000037fffe97dc8 ((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0},\n\t\t\tat: process_one_work+0x232/0x730\n\t\twhich lock already depends on the new lock.\n\t\tthe existing dependency chain (in reverse order) is:\n\t\t-\u003e #4 ((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __flush_work+0x76/0xf0\n\t\t __cancel_work_timer+0x170/0x220\n\t\t __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]\n\t\t smc_connect_rdma+0x15e/0x418 [smc]\n\t\t __smc_connect+0x234/0x480 [smc]\n\t\t smc_connect+0x1d6/0x230 [smc]\n\t\t __sys_connect+0x90/0xc0\n\t\t __do_sys_socketcall+0x186/0x370\n\t\t __do_syscall+0x1da/0x208\n\t\t system_call+0x82/0xb0\n\t\t-\u003e #3 (smc_client_lgr_pending){+.+.}-{3:3}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __mutex_lock+0x96/0x8e8\n\t\t mutex_lock_nested+0x32/0x40\n\t\t smc_connect_rdma+0xa4/0x418 [smc]\n\t\t __smc_connect+0x234/0x480 [smc]\n\t\t smc_connect+0x1d6/0x230 [smc]\n\t\t __sys_connect+0x90/0xc0\n\t\t __do_sys_socketcall+0x186/0x370\n\t\t __do_syscall+0x1da/0x208\n\t\t system_call+0x82/0xb0\n\t\t-\u003e #2 (sk_lock-AF_SMC){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t lock_sock_nested+0x46/0xa8\n\t\t smc_tx_work+0x34/0x50 [smc]\n\t\t process_one_work+0x30c/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\t-\u003e #1 ((work_completion)(\u0026(\u0026smc-\u003econn.tx_work)-\u003ework)){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t process_one_work+0x2bc/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\t-\u003e #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:\n\t\t check_prev_add+0xd8/0xe88\n\t\t validate_chain+0x70c/0xb20\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __flush_workqueue+0xaa/0x4f0\n\t\t drain_workqueue+0xaa/0x158\n\t\t destroy_workqueue+0x44/0x2d8\n\t\t smc_lgr_free+0x9e/0xf8 [smc]\n\t\t process_one_work+0x30c/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\tother info that might help us debug this:\n\t\tChain exists of:\n\t\t (wq_completion)smc_tx_wq-00000000#2\n\t \t --\u003e smc_client_lgr_pending\n\t\t --\u003e (work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)\n\t\t Possible unsafe locking scenario:\n\t\t CPU0 CPU1\n\t\t ---- ----\n\t\t lock((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework));\n\t\t lock(smc_client_lgr_pending);\n\t\t lock((work_completion)\n\t\t\t\t\t(\u0026(\u0026lgr-\u003efree_work)-\u003ework));\n\t\t lock((wq_completion)smc_tx_wq-00000000#2);\n\t\t *** DEADLOCK ***\n\t\t2 locks held by kworker/3:0/176251:\n\t\t #0: 0000000080183548\n\t\t\t((wq_completion)events){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\t #1: 0000037fffe97dc8\n\t\t\t((work_completion)\n\t\t\t (\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\tstack backtr\n---truncated---",
"id": "GHSA-r95c-h52x-x56p",
"modified": "2025-12-04T15:30:32Z",
"published": "2025-09-15T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913"
}
],
"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.