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.
724 vulnerabilities reference this CWE, most recent first.
GHSA-9VC4-746X-P2RF
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
sfc: fix deadlock in RSS config read
Since cited commit, core locks the net_device's rss_lock when handling ethtool -x command, so driver's implementation should not lock it again. Remove the latter.
{
"affected": [],
"aliases": [
"CVE-2026-23165"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix deadlock in RSS config read\n\nSince cited commit, core locks the net_device\u0027s rss_lock when handling\n ethtool -x command, so driver\u0027s implementation should not lock it\n again. Remove the latter.",
"id": "GHSA-9vc4-746x-p2rf",
"modified": "2026-03-18T15:30:40Z",
"published": "2026-02-14T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/590c8179ffb01c17644181408821b55b8704c50c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/944c614b0a7afa5b87612c3fb557b95a50ad654c"
}
],
"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-9WMJ-XCGW-57P9
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22In Lenovo systems, SMM BIOS Write Protection is used to prevent writes to SPI Flash. While this provides sufficient protection, an additional layer of protection is provided by SPI Protected Range Registers (PRx). Lenovo was notified that after resuming from S3 sleep mode in various versions of BIOS for Lenovo systems, the PRx is not set. This does not impact the SMM BIOS Write Protection, which keeps systems protected.
{
"affected": [],
"aliases": [
"CVE-2019-6156"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-10T17:29:00Z",
"severity": "LOW"
},
"details": "In Lenovo systems, SMM BIOS Write Protection is used to prevent writes to SPI Flash. While this provides sufficient protection, an additional layer of protection is provided by SPI Protected Range Registers (PRx). Lenovo was notified that after resuming from S3 sleep mode in various versions of BIOS for Lenovo systems, the PRx is not set. This does not impact the SMM BIOS Write Protection, which keeps systems protected.",
"id": "GHSA-9wmj-xcgw-57p9",
"modified": "2022-05-13T01:22:39Z",
"published": "2022-05-13T01:22:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6156"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/solutions/LEN-26332"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9X65-M9RH-PQXF
Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
bcachefs: grab s_umount only if snapshotting
When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume.
$ cat test.sh prog=bcachefs
$prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots
while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done
$ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log
storage: dbPath: /mnt/data/
lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] ------------------------------------------------------ [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock.
[ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshot_create_lock){++++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notify_change+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 3437.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){.+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] filename_create+0x62/0x190 [ 3437.466175] user_path_create+0x2d/0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this:
[ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this:
[ 3437.467507] Chain exists of: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48
[ 3437.467979] Possible unsafe locking scenario:
[ 3437.468223] CPU0 CPU1 [ 3437.468405] ---- ---- [ 3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] lock(&c->snapshot_create_lock); [ 3437.469030] lock(&type->s_umount_key#48); [ 3437.469291] rlock(sb_writers#10); [ 3437.469434] *** DEADLOCK ***
[ 3437.469 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26658"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcachefs: grab s_umount only if snapshotting\n\nWhen I was testing mongodb over bcachefs with compression,\nthere is a lockdep warning when snapshotting mongodb data volume.\n\n$ cat test.sh\nprog=bcachefs\n\n$prog subvolume create /mnt/data\n$prog subvolume create /mnt/data/snapshots\n\nwhile true;do\n $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)\n sleep 1s\ndone\n\n$ cat /etc/mongodb.conf\nsystemLog:\n destination: file\n logAppend: true\n path: /mnt/data/mongod.log\n\nstorage:\n dbPath: /mnt/data/\n\nlockdep reports:\n[ 3437.452330] ======================================================\n[ 3437.452750] WARNING: possible circular locking dependency detected\n[ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E\n[ 3437.453562] ------------------------------------------------------\n[ 3437.453981] bcachefs/35533 is trying to acquire lock:\n[ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190\n[ 3437.454875]\n but task is already holding lock:\n[ 3437.455268] ffffa0a02b2b10e0 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.456009]\n which lock already depends on the new lock.\n\n[ 3437.456553]\n the existing dependency chain (in reverse order) is:\n[ 3437.457054]\n -\u003e #3 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}:\n[ 3437.457507] down_read+0x3e/0x170\n[ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.458206] __x64_sys_ioctl+0x93/0xd0\n[ 3437.458498] do_syscall_64+0x42/0xf0\n[ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.459155]\n -\u003e #2 (\u0026c-\u003esnapshot_create_lock){++++}-{3:3}:\n[ 3437.459615] down_read+0x3e/0x170\n[ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]\n[ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]\n[ 3437.460686] notify_change+0x1f1/0x4a0\n[ 3437.461283] do_truncate+0x7f/0xd0\n[ 3437.461555] path_openat+0xa57/0xce0\n[ 3437.461836] do_filp_open+0xb4/0x160\n[ 3437.462116] do_sys_openat2+0x91/0xc0\n[ 3437.462402] __x64_sys_openat+0x53/0xa0\n[ 3437.462701] do_syscall_64+0x42/0xf0\n[ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.463359]\n -\u003e #1 (\u0026sb-\u003es_type-\u003ei_mutex_key#15){+.+.}-{3:3}:\n[ 3437.463843] down_write+0x3b/0xc0\n[ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]\n[ 3437.464493] vfs_write+0x21b/0x4c0\n[ 3437.464653] ksys_write+0x69/0xf0\n[ 3437.464839] do_syscall_64+0x42/0xf0\n[ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.465231]\n -\u003e #0 (sb_writers#10){.+.+}-{0:0}:\n[ 3437.465471] __lock_acquire+0x1455/0x21b0\n[ 3437.465656] lock_acquire+0xc6/0x2b0\n[ 3437.465822] mnt_want_write+0x46/0x1a0\n[ 3437.465996] filename_create+0x62/0x190\n[ 3437.466175] user_path_create+0x2d/0x50\n[ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]\n[ 3437.466617] __x64_sys_ioctl+0x93/0xd0\n[ 3437.466791] do_syscall_64+0x42/0xf0\n[ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.467180]\n other info that might help us debug this:\n\n[ 3437.469670] 2 locks held by bcachefs/35533:\n other info that might help us debug this:\n\n[ 3437.467507] Chain exists of:\n sb_writers#10 --\u003e \u0026c-\u003esnapshot_create_lock --\u003e \u0026type-\u003es_umount_key#48\n\n[ 3437.467979] Possible unsafe locking scenario:\n\n[ 3437.468223] CPU0 CPU1\n[ 3437.468405] ---- ----\n[ 3437.468585] rlock(\u0026type-\u003es_umount_key#48);\n[ 3437.468758] lock(\u0026c-\u003esnapshot_create_lock);\n[ 3437.469030] lock(\u0026type-\u003es_umount_key#48);\n[ 3437.469291] rlock(sb_writers#10);\n[ 3437.469434]\n *** DEADLOCK ***\n\n[ 3437.469\n---truncated---",
"id": "GHSA-9x65-m9rh-pqxf",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-02T09:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2acc59dd88d27ad69b66ded80df16c042b04eeec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b41d3fd04c6757b9c2a60a0c5b2609cae9999df"
}
],
"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-9X8P-G64X-M5J5
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-12 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix deadlock between rcu_tasks_trace and event_mutex.
Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()
There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case.
CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)
Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.
{
"affected": [],
"aliases": [
"CVE-2025-37884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock between rcu_tasks_trace and event_mutex.\n\nFix the following deadlock:\nCPU A\n_free_event()\n perf_kprobe_destroy()\n mutex_lock(\u0026event_mutex)\n perf_trace_event_unreg()\n synchronize_rcu_tasks_trace()\n\nThere are several paths where _free_event() grabs event_mutex\nand calls sync_rcu_tasks_trace. Above is one such case.\n\nCPU B\nbpf_prog_test_run_syscall()\n rcu_read_lock_trace()\n bpf_prog_run_pin_on_cpu()\n bpf_prog_load()\n bpf_tracing_func_proto()\n trace_set_clr_event()\n mutex_lock(\u0026event_mutex)\n\nDelegate trace_set_clr_event() to workqueue to avoid\nsuch lock dependency.",
"id": "GHSA-9x8p-g64x-m5j5",
"modified": "2025-11-12T21:31:03Z",
"published": "2025-05-09T09:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/255cbc9db7067a83713fd2f4b31034ddd266549a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45286680b385f2592db3003554872388dee66d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4580f4e0ebdf8dc8d506ae926b88510395a0c1d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5a528a34e1f613565115a7a6016862ccbfcb9ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5c833f6375f8ecf9254dd27946c927c7d645421"
},
{
"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-9XMP-2MMM-6X5G
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A
{
"affected": [],
"aliases": [
"CVE-2020-0423"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-14T14:15:00Z",
"severity": "HIGH"
},
"details": "In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A",
"id": "GHSA-9xmp-2mmm-6x5g",
"modified": "2022-05-24T17:30:38Z",
"published": "2022-05-24T17:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0423"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00015.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-10-01"
}
],
"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-9XQ7-8P44-P7P4
Vulnerability from github – Published: 2026-06-18 15:32 – Updated: 2026-06-18 18:35[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.
{
"affected": [],
"aliases": [
"CVE-2026-42490"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-18T14:17:25Z",
"severity": "MODERATE"
},
"details": "[This CNA information record relates to multiple CVEs; the\ntext explains which aspects/vulnerabilities correspond to which CVE.]\n\nTo create and manage guests, domctl operations are used by the control\ndomain, a possible Xenstore domain, or by a domain controlling a\nparticular guest. Some of these operations may not be executed in\nparallel, so a system-wide lock is used. The way that lock is acquired\nis, however, not providing any fairness. This is CVE-2026-42489.\n\nFurthermore, with XSM/Flask in use, the lock acquire will, for some\noperations, occur ahead of any permission checking. This is\nCVE-2026-42490.",
"id": "GHSA-9xq7-8p44-p7p4",
"modified": "2026-06-18T18:35:21Z",
"published": "2026-06-18T15:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42490"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-492.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C2CR-W322-FPPQ
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup during bt pages loop
Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup:
watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
...
Call trace:
hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x118/0x290
watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
...
Call trace:
hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x120/0x2bc
Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched().
{
"affected": [],
"aliases": [
"CVE-2025-22010"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix soft lockup during bt pages loop\n\nDriver runs a for-loop when allocating bt pages and mapping them with\nbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,\nit may require a considerable loop count. This will lead to soft lockup:\n\n watchdog: BUG: soft lockup - CPU#27 stuck for 22s!\n ...\n Call trace:\n hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]\n hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]\n alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x118/0x290\n\n watchdog: BUG: soft lockup - CPU#35 stuck for 23s!\n ...\n Call trace:\n hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]\n mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]\n alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x120/0x2bc\n\nAdd a cond_resched() to fix soft lockup during these loops. In order not\nto affect the allocation performance of normal-size buffer, set the loop\ncount of a 100GB MR as the threshold to call cond_resched().",
"id": "GHSA-c2cr-w322-fppq",
"modified": "2025-11-03T21:33:30Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25655580136de59ec89f09089dd28008ea440fc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4104b0023ff66b5df900d23dbf38310893deca79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/461eb4ddede266df8f181f578732bb01742c3fd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/975355faba56c0751292ed15a90c3e2c7dc0aad6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ab20fec7a1ce3057ad86afd27bfd08420b7cd11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efe544462fc0b499725364f90bd0f8bbf16f861a"
},
{
"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-C34Q-8XRW-G745
Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-06-03 18:53In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix a nested dead lock as part of ODP flow
Fix a nested dead lock as part of ODP flow by using mmput_async().
From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex.
Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available.
[1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? process_one_work+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? set_kthread_struct+0x50/0x50 [64843.078085] ret_from_fork+0x22/0x30 [64843.078093]
{
"affected": [],
"aliases": [
"CVE-2022-48675"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T15:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/core: Fix a nested dead lock as part of ODP flow\n\nFix a nested dead lock as part of ODP flow by using mmput_async().\n\nFrom the below call trace [1] can see that calling mmput() once we have\nthe umem_odp-\u003eumem_mutex locked as required by\nib_umem_odp_map_dma_and_lock() might trigger in the same task the\nexit_mmap()-\u003e__mmu_notifier_release()-\u003emlx5_ib_invalidate_range() which\nmay dead lock when trying to lock the same mutex.\n\nMoving to use mmput_async() will solve the problem as the above\nexit_mmap() flow will be called in other task and will be executed once\nthe lock will be available.\n\n[1]\n[64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:\n2 flags:0x00004000\n[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]\n[64843.077719] Call Trace:\n[64843.077722] \u003cTASK\u003e\n[64843.077724] __schedule+0x23d/0x590\n[64843.077729] schedule+0x4e/0xb0\n[64843.077735] schedule_preempt_disabled+0xe/0x10\n[64843.077740] __mutex_lock.constprop.0+0x263/0x490\n[64843.077747] __mutex_lock_slowpath+0x13/0x20\n[64843.077752] mutex_lock+0x34/0x40\n[64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]\n[64843.077808] __mmu_notifier_release+0x1a4/0x200\n[64843.077816] exit_mmap+0x1bc/0x200\n[64843.077822] ? walk_page_range+0x9c/0x120\n[64843.077828] ? __cond_resched+0x1a/0x50\n[64843.077833] ? mutex_lock+0x13/0x40\n[64843.077839] ? uprobe_clear_state+0xac/0x120\n[64843.077860] mmput+0x5f/0x140\n[64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]\n[64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib]\n[64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib]\n[64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560\n[mlx5_ib]\n[64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]\n[64843.078051] process_one_work+0x22b/0x3d0\n[64843.078059] worker_thread+0x53/0x410\n[64843.078065] ? process_one_work+0x3d0/0x3d0\n[64843.078073] kthread+0x12a/0x150\n[64843.078079] ? set_kthread_struct+0x50/0x50\n[64843.078085] ret_from_fork+0x22/0x30\n[64843.078093] \u003c/TASK\u003e",
"id": "GHSA-c34q-8xrw-g745",
"modified": "2024-06-03T18:53:45Z",
"published": "2024-05-03T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48675"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f"
}
],
"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-C3J4-C39C-W5R2
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
smb/server: avoid deadlock when linking with ReplaceIfExists
If smb2_create_link() is called with ReplaceIfExists set and the name does exist then a deadlock will happen.
ksmbd_vfs_kern_path_locked() will return with success and the parent directory will be locked. ksmbd_vfs_remove_file() will then remove the file. ksmbd_vfs_link() will then be called while the parent is still locked. It will try to lock the same parent and will deadlock.
This patch moves the ksmbd_vfs_kern_path_unlock() call to before ksmbd_vfs_link() and then simplifies the code, removing the file_present flag variable.
{
"affected": [],
"aliases": [
"CVE-2025-38711"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-04T16:15:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: avoid deadlock when linking with ReplaceIfExists\n\nIf smb2_create_link() is called with ReplaceIfExists set and the name\ndoes exist then a deadlock will happen.\n\nksmbd_vfs_kern_path_locked() will return with success and the parent\ndirectory will be locked. ksmbd_vfs_remove_file() will then remove the\nfile. ksmbd_vfs_link() will then be called while the parent is still\nlocked. It will try to lock the same parent and will deadlock.\n\nThis patch moves the ksmbd_vfs_kern_path_unlock() call to *before*\nksmbd_vfs_link() and then simplifies the code, removing the file_present\nflag variable.",
"id": "GHSA-c3j4-c39c-w5r2",
"modified": "2026-05-12T15:31:01Z",
"published": "2025-09-05T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38711"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e858a7a51c7b8b009d8f246de7ceb7743b44a71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/814cfdb6358d9b84fcbec9918c8f938cc096a43a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5012ffe14120f978ee34aef4df3d6cb026b7c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a726fef6d7d4cfc365d3434e3916dbfe78991a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7dddd62578c2eb6cb28b8835556a121b5157323"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac98d54630d5b52e3f684d872f0d82c06c418ea9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5fc1400a34b4ea5e8f2ce296ea12bf8c8421694"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C4CJ-X9MV-WWGX
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
Coverity spotted that the cifs_sync_mid_result function could deadlock
"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"
Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
{
"affected": [],
"aliases": [
"CVE-2024-35998"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix lock ordering potential deadlock in cifs_sync_mid_result\n\nCoverity spotted that the cifs_sync_mid_result function could deadlock\n\n\"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires\nlock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock\"\n\nAddresses-Coverity: 1590401 (\"Thread deadlock (ORDER_REVERSAL)\")",
"id": "GHSA-c4cj-x9mv-wwgx",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35998"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66"
}
],
"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.