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.
720 vulnerabilities reference this CWE, most recent first.
GHSA-QGMQ-76M4-C2JV
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-03-25 15:31In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix deadlock during uvc_probe
If uvc_probe() fails, it can end up calling uvc_status_unregister() before uvc_status_init() is called.
Fix this by checking if dev->status is NULL or not in uvc_status_unregister().
{
"affected": [],
"aliases": [
"CVE-2024-58059"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix deadlock during uvc_probe\n\nIf uvc_probe() fails, it can end up calling uvc_status_unregister() before\nuvc_status_init() is called.\n\nFix this by checking if dev-\u003estatus is NULL or not in\nuvc_status_unregister().",
"id": "GHSA-qgmq-76m4-c2jv",
"modified": "2025-03-25T15:31:22Z",
"published": "2025-03-06T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58059"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a67f75c2b5ecf534eab416ce16c11fe780c4f8f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db577ededf3a18b39567fc1a6209f12a0c4a3c52"
}
],
"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-QHPW-2QGQ-68PX
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix locking usage for tcon fields
We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.
There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock.
{
"affected": [],
"aliases": [
"CVE-2026-43215"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:41Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix locking usage for tcon fields\n\nWe used to use the cifs_tcp_ses_lock to protect a lot of objects\nthat are not just the server, ses or tcon lists. We later introduced\nsrv_lock, ses_lock and tc_lock to protect fields within the\ncorresponding structs. This was done to provide a more granular\nprotection and avoid unnecessary serialization.\n\nThere were still a couple of uses of cifs_tcp_ses_lock to provide\ntcon fields. In this patch, I\u0027ve replaced them with tc_lock.",
"id": "GHSA-qhpw-2qgq-68px",
"modified": "2026-05-08T15:31:18Z",
"published": "2026-05-06T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43215"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3969db6b22e3d90d8c5f22ac1a7fe0350a94c136"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/601dd3b79769b38d30b693c40afdb2a4b7edf9d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c59eeeeffa1524ef57e173a89a1a3ff539888d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/953953abb66e52c224057ab91e404284fefeab62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96c4af418586ee9a6aab61738644366426e05316"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QJVC-XMQV-CWR9
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
{
"affected": [],
"aliases": [
"CVE-2024-50044"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:17Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change\n\nrfcomm_sk_state_change attempts to use sock_lock so it must never be\ncalled with it locked but rfcomm_sock_ioctl always attempt to lock it\ncausing the following trace:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted\n------------------------------------------------------\nsyz-executor386/5093 is trying to acquire lock:\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73\n\nbut task is already holding lock:\nffff88807badfd28 (\u0026d-\u003elock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491",
"id": "GHSA-qjvc-xmqv-cwr9",
"modified": "2026-05-12T15:30:39Z",
"published": "2024-10-21T21:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50044"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08d1914293dae38350b8088980e59fbc699a72fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38b2d5a57d125e1c17661b8308c0240c4a43b534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/496b2ab0fd10f205e08909a125485fdc98843dbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cb9807c9b53bf1e5560420d26f319f528b50268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/869c6ee62ab8f01bf2419e45326642be5c9b670a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b77b3fb12fd483cae7c28648903b1d8a6b275f01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ced98072d3511b232ae1d3347945f35f30c0e303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef44274dae9b0a90d1a97ce8b242a3b8243a7745"
},
{
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-QQ67-P454-7JFC
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2025-03-07 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix another deadlock during RTC update
If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.
Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-53053"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix another deadlock during RTC update\n\nIf ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm\u0027s usage_count\nis 0, we will enter the runtime suspend callback. However, the runtime\nsuspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.\n\nReplace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the\ndeadlock.",
"id": "GHSA-qq67-p454-7jfc",
"modified": "2025-03-07T18:31:01Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9aa1f0da237d6b16e36e0a0cc9f746d1d78396ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a128cfec44709ab1bd1f01d158569bcb2386f54f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb7e509c4e0197f63717fee54fb41c4990ba8d3a"
}
],
"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-QRPM-P5HJ-4XG3
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2025-10-03 15:31In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]
{
"affected": [],
"aliases": [
"CVE-2024-38634"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: max3100: Lock port-\u003elock when calling uart_handle_cts_change()\n\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0027s taken by explicitly doing\nthat. Without it we got a splat:\n\n WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n ...\n Workqueue: max3100-0 max3100_work [max3100]\n RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n ...\n max3100_handlerx+0xc5/0x110 [max3100]\n max3100_work+0x12a/0x340 [max3100]",
"id": "GHSA-qrpm-p5hj-4xg3",
"modified": "2025-10-03T15:31:13Z",
"published": "2024-06-21T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44b38924135d2093e2ec1812969464845dd66dc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77ab53371a2066fdf9b895246505f5ef5a4b5d47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78dbda51bb4241b88a52d71620f06231a341f9ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8296bb9e5925b6634259c5d4daee88f0cc0884ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/865b30c8661924ee9145f442bf32cea549faa869"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93df2fba6c7dfa9a2f08546ea9a5ca4728758458"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc121e3722a0a2c8f716ef991e5425b180a5fb94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea9b35372b58ac2931bfc1d5bc25e839d1221e30"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-QV39-HG6Q-9R5R
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:
- File A has inode i_reg and an ea inode i_ea
- getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
-
Then, following three processes running like this:
PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:
- File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
- getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
- Then, following three processes running like this:
PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-45003"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T20:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0027t evict inode under the inode lru traversing context\n\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\n\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\n\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u003ei_ea\n 3. Then, following three processes running like this:\n\n PA PB\n echo 2 \u003e /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // i_reg is added into lru, lru-\u003ei_ea-\u003ei_reg\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n i_ea-\u003ei_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(i_reg)\n spin_unlock(\u0026i_reg-\u003ei_lock)\n spin_unlock(lru_lock)\n rm file A\n i_reg-\u003enlink = 0\n iput(i_reg) // i_reg-\u003enlink is 0, do evict\n ext4_evict_inode\n ext4_xattr_delete_inode\n ext4_xattr_inode_dec_ref_all\n ext4_xattr_inode_iget\n ext4_iget(i_ea-\u003ei_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026i_ea-\u003ei_state)\n\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n deleting process holds BASEHD\u0027s wbuf-\u003eio_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n reclaiming process could try locking BASEHD\u0027s wbuf-\u003eio_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\n\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u003eixa\n 3. Then, following three processes running like this:\n\n PA PB PC\n echo 2 \u003e /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // ib and ia are added into lru, lru-\u003eixa-\u003eib-\u003eia\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n ixa-\u003ei_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(ib)\n spin_unlock(\u0026ib-\u003ei_lock)\n spin_unlock(lru_lock)\n rm file B\n ib-\u003enlink = 0\n rm file A\n iput(ia)\n ubifs_evict_inode(ia)\n ubifs_jnl_delete_inode(ia)\n ubifs_jnl_write_inode(ia)\n make_reservation(BASEHD) // Lock wbuf-\u003eio_mutex\n ubifs_iget(ixa-\u003ei_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(ixa)\n | iput(ib) // ib-\u003enlink is 0, do evict\n | ubifs_evict_inode\n | ubifs_jnl_delete_inode(ib)\n \u2193 ubifs_jnl_write_inode\n ABBA deadlock \u2190-----make_reservation(BASEHD)\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026ixa-\u003ei_state)\n\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---",
"id": "GHSA-qv39-hg6q-9r5r",
"modified": "2025-11-04T00:31:23Z",
"published": "2024-09-04T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QV7C-PJPR-GRQX
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2025-02-28 00:30In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
There is chip (ls1028a) errata:
The SoC may hang on 16 byte unaligned read transactions by QDMA.
Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller.
Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
Implement this workaround.
{
"affected": [],
"aliases": [
"CVE-2024-26790"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.",
"id": "GHSA-qv7c-pjpr-grqx",
"modified": "2025-02-28T00:30:51Z",
"published": "2024-04-04T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-QV7H-6R58-HCX8
Vulnerability from github – Published: 2025-12-16 15:30 – Updated: 2026-02-26 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: delete radeon_fence_process in is_signaled, no deadlock
Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock.
dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable.
(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
{
"affected": [],
"aliases": [
"CVE-2025-68223"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T14:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: delete radeon_fence_process in is_signaled, no deadlock\n\nDelete the attempt to progress the queue when checking if fence is\nsignaled. This avoids deadlock.\n\ndma-fence_ops::signaled can be called with the fence lock in unknown\nstate. For radeon, the fence lock is also the wait queue lock. This can\ncause a self deadlock when signaled() tries to make forward progress on\nthe wait queue. But advancing the queue is unneeded because incorrectly\nreturning false from signaled() is perfectly acceptable.\n\n(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)",
"id": "GHSA-qv7h-6r58-hcx8",
"modified": "2026-02-26T18:31:34Z",
"published": "2025-12-16T15:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68223"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73bc12d6a547f9571ce4393acfd73c004e2df9e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e3e9b3a44c23c8eac86a41308c05077d6d30f41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d0ed508a9e2af82951ce7d834f58c139fc2bd9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9eb00b5f5697bd56baa3222c7a1426fa15bacfb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d40a72d7e3bad4dfb311ef078f5a57362f088c7f"
}
],
"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-QV92-QXR2-XV3J
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory.
Grab the same locks the other two callers use.
{
"affected": [],
"aliases": [
"CVE-2026-46112"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:26Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix unlocked call to hns_roce_qp_remove()\n\nSashiko points out that hns_roce_qp_remove() requires the caller to hold\nlocks. The error flow in hns_roce_create_qp_common() doesn\u0027t hold those\nlocks for the error unwind so it risks corrupting memory.\n\nGrab the same locks the other two callers use.",
"id": "GHSA-qv92-qxr2-xv3j",
"modified": "2026-06-01T18:31:36Z",
"published": "2026-05-28T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46112"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c99acbc8b6c6dd526ae475a48ee1897b61072fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1912f78798505dc9c637081bbddfbf1c22494c49"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f0a3aa8b569d010316b427238222c5d899f9618"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/615d9d260c32bb678504ca96f29ae46f9d745155"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6296ff2475fc95ee6ea1b528c4b385302808186"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb4ae739811d467409bd07d0e36cfd4140f3d26a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcf6a832c0d5b2bc5398d6996c5570d3ee7993fb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QVJJ-9XG3-CHP9
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
net: phy: register phy led_triggers during probe to avoid AB-BA deadlock
There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled:
[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58
Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock.
[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58
Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock.
phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-23368"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: register phy led_triggers during probe to avoid AB-BA deadlock\n\nThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and\nLED_TRIGGER_PHY are enabled:\n\n[ 1362.049207] [\u003c8054e4b8\u003e] led_trigger_register+0x5c/0x1fc \u003c-- Trying to get lock \"triggers_list_lock\" via down_write(\u0026triggers_list_lock);\n[ 1362.054536] [\u003c80662830\u003e] phy_led_triggers_register+0xd0/0x234\n[ 1362.060329] [\u003c8065e200\u003e] phy_attach_direct+0x33c/0x40c\n[ 1362.065489] [\u003c80651fc4\u003e] phylink_fwnode_phy_connect+0x15c/0x23c\n[ 1362.071480] [\u003c8066ee18\u003e] mtk_open+0x7c/0xba0\n[ 1362.075849] [\u003c806d714c\u003e] __dev_open+0x280/0x2b0\n[ 1362.080384] [\u003c806d7668\u003e] __dev_change_flags+0x244/0x24c\n[ 1362.085598] [\u003c806d7698\u003e] dev_change_flags+0x28/0x78\n[ 1362.090528] [\u003c807150e4\u003e] dev_ioctl+0x4c0/0x654 \u003c-- Hold lock \"rtnl_mutex\" by calling rtnl_lock();\n[ 1362.094985] [\u003c80694360\u003e] sock_ioctl+0x2f4/0x4e0\n[ 1362.099567] [\u003c802e9c4c\u003e] sys_ioctl+0x32c/0xd8c\n[ 1362.104022] [\u003c80014504\u003e] syscall_common+0x34/0x58\n\nHere LED_TRIGGER_PHY is registering LED triggers during phy_attach\nwhile holding RTNL and then taking triggers_list_lock.\n\n[ 1362.191101] [\u003c806c2640\u003e] register_netdevice_notifier+0x60/0x168 \u003c-- Trying to get lock \"rtnl_mutex\" via rtnl_lock();\n[ 1362.197073] [\u003c805504ac\u003e] netdev_trig_activate+0x194/0x1e4\n[ 1362.202490] [\u003c8054e28c\u003e] led_trigger_set+0x1d4/0x360 \u003c-- Hold lock \"triggers_list_lock\" by down_read(\u0026triggers_list_lock);\n[ 1362.207511] [\u003c8054eb38\u003e] led_trigger_write+0xd8/0x14c\n[ 1362.212566] [\u003c80381d98\u003e] sysfs_kf_bin_write+0x80/0xbc\n[ 1362.217688] [\u003c8037fcd8\u003e] kernfs_fop_write_iter+0x17c/0x28c\n[ 1362.223174] [\u003c802cbd70\u003e] vfs_write+0x21c/0x3c4\n[ 1362.227712] [\u003c802cc0c4\u003e] ksys_write+0x78/0x12c\n[ 1362.232164] [\u003c80014504\u003e] syscall_common+0x34/0x58\n\nHere LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes\ntriggers_list_lock and then RTNL. A classical AB-BA deadlock.\n\nphy_led_triggers_registers() does not require the RTNL, it does not\nmake any calls into the network stack which require protection. There\nis also no requirement the PHY has been attached to a MAC, the\ntriggers only make use of phydev state. This allows the call to\nphy_led_triggers_registers() to be placed elsewhere. PHY probe() and\nrelease() don\u0027t hold RTNL, so solving the AB-BA deadlock.",
"id": "GHSA-qvjj-9xg3-chp9",
"modified": "2026-07-14T15:31:42Z",
"published": "2026-03-25T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23368"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/241cd64cf2e32b28ead151b1795cd8fef2b6e482"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2764dcb3c35de4410f642afc62cf979727470575"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b01518eabace18f7ec8b4cafd52082303080dca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/305afdd02ff3e694c165457793104710ec0728e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c33523b8fd2d4c504ada18cd93f511f2a8f84217"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6ffc2d2338d325e1edd0c702e3ee623aa5fdc6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8dbdc6e380e7e96a51706db3e4b7870d8a9402d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cde2d0b5ab5d03b5b6f17d4f654d8b30ccf36757"
}
],
"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.