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.
753 vulnerabilities reference this CWE, most recent first.
GHSA-3JVQ-9RG9-G8RP
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2024-12-06 21:30In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: avoid deadlock between hci_dev->lock and socket lock
Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock.
It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock.
This fixes the lockdep splat below:
====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted
bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth]
but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30
-> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock);
*** DEADLOCK ***
1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth]
stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47038"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: avoid deadlock between hci_dev-\u003elock and socket lock\n\nCommit eab2404ba798 (\"Bluetooth: Add BT_PHY socket option\") added a\ndependency between socket lock and hci_dev-\u003elock that could lead to\ndeadlock.\n\nIt turns out that hci_conn_get_phy() is not in any way relying on hdev\nbeing immutable during the runtime of this function, neither does it even\nlook at any of the members of hdev, and as such there is no need to hold\nthat lock.\n\nThis fixes the lockdep splat below:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 5.12.0-rc1-00026-g73d464503354 #10 Not tainted\n ------------------------------------------------------\n bluetoothd/1118 is trying to acquire lock:\n ffff8f078383c078 (\u0026hdev-\u003elock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth]\n\n but task is already holding lock:\n ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}:\n lock_sock_nested+0x72/0xa0\n l2cap_sock_ready_cb+0x18/0x70 [bluetooth]\n l2cap_config_rsp+0x27a/0x520 [bluetooth]\n l2cap_sig_channel+0x658/0x1330 [bluetooth]\n l2cap_recv_frame+0x1ba/0x310 [bluetooth]\n hci_rx_work+0x1cc/0x640 [bluetooth]\n process_one_work+0x244/0x5f0\n worker_thread+0x3c/0x380\n kthread+0x13e/0x160\n ret_from_fork+0x22/0x30\n\n -\u003e #2 (\u0026chan-\u003elock#2/1){+.+.}-{3:3}:\n __mutex_lock+0xa3/0xa10\n l2cap_chan_connect+0x33a/0x940 [bluetooth]\n l2cap_sock_connect+0x141/0x2a0 [bluetooth]\n __sys_connect+0x9b/0xc0\n __x64_sys_connect+0x16/0x20\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n -\u003e #1 (\u0026conn-\u003echan_lock){+.+.}-{3:3}:\n __mutex_lock+0xa3/0xa10\n l2cap_chan_connect+0x322/0x940 [bluetooth]\n l2cap_sock_connect+0x141/0x2a0 [bluetooth]\n __sys_connect+0x9b/0xc0\n __x64_sys_connect+0x16/0x20\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n -\u003e #0 (\u0026hdev-\u003elock){+.+.}-{3:3}:\n __lock_acquire+0x147a/0x1a50\n lock_acquire+0x277/0x3d0\n __mutex_lock+0xa3/0xa10\n hci_conn_get_phy+0x1c/0x150 [bluetooth]\n l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth]\n __sys_getsockopt+0xcc/0x200\n __x64_sys_getsockopt+0x20/0x30\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n other info that might help us debug this:\n\n Chain exists of:\n \u0026hdev-\u003elock --\u003e \u0026chan-\u003elock#2/1 --\u003e sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);\n lock(\u0026chan-\u003elock#2/1);\n lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);\n lock(\u0026hdev-\u003elock);\n\n *** DEADLOCK ***\n\n 1 lock held by bluetoothd/1118:\n #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth]\n\n stack backtrace:\n CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10\n Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017\n Call Trace:\n dump_stack+0x7f/0xa1\n check_noncircular+0x105/0x120\n ? __lock_acquire+0x147a/0x1a50\n __lock_acquire+0x147a/0x1a50\n lock_acquire+0x277/0x3d0\n ? hci_conn_get_phy+0x1c/0x150 [bluetooth]\n ? __lock_acquire+0x2e1/0x1a50\n ? lock_is_held_type+0xb4/0x120\n ? hci_conn_get_phy+0x1c/0x150 [bluetooth]\n __mutex_lock+0xa3/0xa10\n ? hci_conn_get_phy+0x1c/0x150 [bluetooth]\n ? lock_acquire+0x277/0x3d0\n ? mark_held_locks+0x49/0x70\n ? mark_held_locks+0x49/0x70\n ? hci_conn_get_phy+0x1c/0x150 [bluetooth]\n hci_conn_get_phy+0x\n---truncated---",
"id": "GHSA-3jvq-9rg9-g8rp",
"modified": "2024-12-06T21:30:35Z",
"published": "2024-02-28T09:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47038"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17486960d79b900c45e0bb8fbcac0262848582ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/332e69eb3bd90370f2d9f2c2ca7974ff523dea17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cc0ba67883c6c8d3bddb283f56c167fc837a555"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fee71f480bc1dec5f6ae3b0b185ff12a62bceabc"
}
],
"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-3M73-M9XC-48PV
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 15:30In the Linux kernel, the following vulnerability has been resolved:
dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang:
1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang:
[root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
This is because reshape can't make progress.
For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more:
1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO.
{
"affected": [],
"aliases": [
"CVE-2024-26962"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape\n\nFor raid456, if reshape is still in progress, then IO across reshape\nposition will wait for reshape to make progress. However, for dm-raid,\nin following cases reshape will never make progress hence IO will hang:\n\n1) the array is read-only;\n2) MD_RECOVERY_WAIT is set;\n3) MD_RECOVERY_FROZEN is set;\n\nAfter commit c467e97f079f (\"md/raid6: use valid sector values to determine\nif an I/O should wait on the reshape\") fix the problem that IO across\nreshape position doesn\u0027t wait for reshape, the dm-raid test\nshell/lvconvert-raid-reshape.sh start to hang:\n\n[root@fedora ~]# cat /proc/979/stack\n[\u003c0\u003e] wait_woken+0x7d/0x90\n[\u003c0\u003e] raid5_make_request+0x929/0x1d70 [raid456]\n[\u003c0\u003e] md_handle_request+0xc2/0x3b0 [md_mod]\n[\u003c0\u003e] raid_map+0x2c/0x50 [dm_raid]\n[\u003c0\u003e] __map_bio+0x251/0x380 [dm_mod]\n[\u003c0\u003e] dm_submit_bio+0x1f0/0x760 [dm_mod]\n[\u003c0\u003e] __submit_bio+0xc2/0x1c0\n[\u003c0\u003e] submit_bio_noacct_nocheck+0x17f/0x450\n[\u003c0\u003e] submit_bio_noacct+0x2bc/0x780\n[\u003c0\u003e] submit_bio+0x70/0xc0\n[\u003c0\u003e] mpage_readahead+0x169/0x1f0\n[\u003c0\u003e] blkdev_readahead+0x18/0x30\n[\u003c0\u003e] read_pages+0x7c/0x3b0\n[\u003c0\u003e] page_cache_ra_unbounded+0x1ab/0x280\n[\u003c0\u003e] force_page_cache_ra+0x9e/0x130\n[\u003c0\u003e] page_cache_sync_ra+0x3b/0x110\n[\u003c0\u003e] filemap_get_pages+0x143/0xa30\n[\u003c0\u003e] filemap_read+0xdc/0x4b0\n[\u003c0\u003e] blkdev_read_iter+0x75/0x200\n[\u003c0\u003e] vfs_read+0x272/0x460\n[\u003c0\u003e] ksys_read+0x7a/0x170\n[\u003c0\u003e] __x64_sys_read+0x1c/0x30\n[\u003c0\u003e] do_syscall_64+0xc6/0x230\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nThis is because reshape can\u0027t make progress.\n\nFor md/raid, the problem doesn\u0027t exist because register new sync_thread\ndoesn\u0027t rely on the IO to be done any more:\n\n1) If array is read-only, it can switch to read-write by ioctl/sysfs;\n2) md/raid never set MD_RECOVERY_WAIT;\n3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn\u0027t hold\n \u0027reconfig_mutex\u0027, hence it can be cleared and reshape can continue by\n sysfs api \u0027sync_action\u0027.\n\nHowever, I\u0027m not sure yet how to avoid the problem in dm-raid yet. This\npatch on the one hand make sure raid_message() can\u0027t change\nsync_thread() through raid_message() after presuspend(), on the other\nhand detect the above 3 cases before wait for IO do be done in\ndm_suspend(), and let dm-raid requeue those IO.",
"id": "GHSA-3m73-m9xc-48pv",
"modified": "2024-12-23T15:30:46Z",
"published": "2024-05-01T06:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26962"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"
}
],
"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-3PG2-Q6Q7-9RMM
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
iio: adis16475: fix deadlock on frequency set
With commit 39c024b51b560 ("iio: adis16475: improve sync scale mode handling"), two deadlocks were introduced: 1) The call to 'adis_write_reg_16()' was not changed to it's unlocked version. 2) The lock was not being released on the success path of the function.
This change fixes both these issues.
{
"affected": [],
"aliases": [
"CVE-2021-47437"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T07:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: adis16475: fix deadlock on frequency set\n\nWith commit 39c024b51b560\n(\"iio: adis16475: improve sync scale mode handling\"), two deadlocks were\nintroduced:\n 1) The call to \u0027adis_write_reg_16()\u0027 was not changed to it\u0027s unlocked\n version.\n 2) The lock was not being released on the success path of the function.\n\nThis change fixes both these issues.",
"id": "GHSA-3pg2-q6q7-9rmm",
"modified": "2025-01-10T18:31:38Z",
"published": "2024-05-22T09:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47437"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04e03b907022ebd876f422f17efcc2c6cc934dc6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9da1b86865ab4376408c58cd9fec332c8bdb5c73"
}
],
"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-3Q3C-Q46P-RWCG
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-08-11 18:30In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix shrinker deadlock
With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:
====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W
kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm]
but task is already holding lock: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 fs_reclaim_acquire+0xd0/0xf0 dma_resv_lockdep+0x224/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20
-> #1 (reservation_ww_class_mutex){+.+.}-{4:4}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 dma_resv_lockdep+0x1a8/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20
-> #0 (reservation_ww_class_acquire){+.+.}-{0:0}: check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0 __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20
other info that might help us debug this: Chain exists of: reservation_ww_class_acquire --> reservation_ww_class_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(reservation_ww_class_mutex); lock(fs_reclaim); lock(reservation_ww_class_acquire);
*** DEADLOCK ***
1 lock held by kswapd0/82: #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988
stack backtrace: CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full) Tainted: [W]=WARN Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025 Call trace: show_stack+0x20/0x40 (C) dump_stack_lvl+0x9c/0xd0 dump_stack+0x18/0x30 print_circular_bug+0x114/0x120 check_noncircular+0x178/0x198 check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0 __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20
kswapd0 holding fs_reclaim calls the MSM shrinker, which calls dma_resv_lock. This in turn acquires fs_reclaim.
Fix this deadlock by using dma_resv_trylock() instead, dropping the subsequently unused passed wait-wound lock 'ticket'.
Patchwork: https://patchwork.freedesktop.org/patch/723564/ [rob: fixup compile errors, replace lockdep splat with somethin ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-64100"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Fix shrinker deadlock\n\nWith PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 7.0.0-debug+ #43 Tainted: G W\n ------------------------------------------------------\n kswapd0/82 is trying to acquire lock:\n ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm]\n\n but task is already holding lock:\n ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #2 (fs_reclaim){+.+.}-{0:0}:\n __lock_acquire+0x4d0/0xad0\n lock_acquire.part.0+0xc4/0x248\n lock_acquire+0x8c/0x248\n fs_reclaim_acquire+0xd0/0xf0\n dma_resv_lockdep+0x224/0x348\n do_one_initcall+0x84/0x5d0\n do_initcalls+0x194/0x1d8\n kernel_init_freeable+0x128/0x180\n kernel_init+0x2c/0x160\n ret_from_fork+0x10/0x20\n\n -\u003e #1 (reservation_ww_class_mutex){+.+.}-{4:4}:\n __lock_acquire+0x4d0/0xad0\n lock_acquire.part.0+0xc4/0x248\n lock_acquire+0x8c/0x248\n dma_resv_lockdep+0x1a8/0x348\n do_one_initcall+0x84/0x5d0\n do_initcalls+0x194/0x1d8\n kernel_init_freeable+0x128/0x180\n kernel_init+0x2c/0x160\n ret_from_fork+0x10/0x20\n\n -\u003e #0 (reservation_ww_class_acquire){+.+.}-{0:0}:\n check_prev_add+0x114/0x790\n validate_chain+0x594/0x6f0\n __lock_acquire+0x4d0/0xad0\n lock_acquire.part.0+0xc4/0x248\n lock_acquire+0x8c/0x248\n drm_gem_lru_scan+0x1ac/0x440\n msm_gem_shrinker_scan+0x17c/0x400 [msm]\n do_shrink_slab+0x150/0x4a0\n shrink_slab+0x144/0x460\n shrink_one+0x9c/0x1b0\n shrink_many+0x27c/0x5c0\n shrink_node+0x344/0x550\n balance_pgdat+0x2c0/0x988\n kswapd+0x11c/0x318\n kthread+0x10c/0x128\n ret_from_fork+0x10/0x20\n\n other info that might help us debug this:\n Chain exists of:\n reservation_ww_class_acquire --\u003e reservation_ww_class_mutex --\u003e fs_reclaim\n Possible unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(fs_reclaim);\n lock(reservation_ww_class_mutex);\n lock(fs_reclaim);\n lock(reservation_ww_class_acquire);\n\n *** DEADLOCK ***\n 1 lock held by kswapd0/82:\n #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988\n\n stack backtrace:\n CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full)\n Tainted: [W]=WARN\n Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025\n Call trace:\n show_stack+0x20/0x40 (C)\n dump_stack_lvl+0x9c/0xd0\n dump_stack+0x18/0x30\n print_circular_bug+0x114/0x120\n check_noncircular+0x178/0x198\n check_prev_add+0x114/0x790\n validate_chain+0x594/0x6f0\n __lock_acquire+0x4d0/0xad0\n lock_acquire.part.0+0xc4/0x248\n lock_acquire+0x8c/0x248\n drm_gem_lru_scan+0x1ac/0x440\n msm_gem_shrinker_scan+0x17c/0x400 [msm]\n do_shrink_slab+0x150/0x4a0\n shrink_slab+0x144/0x460\n shrink_one+0x9c/0x1b0\n shrink_many+0x27c/0x5c0\n shrink_node+0x344/0x550\n balance_pgdat+0x2c0/0x988\n kswapd+0x11c/0x318\n kthread+0x10c/0x128\n ret_from_fork+0x10/0x20\n\nkswapd0 holding fs_reclaim calls the MSM shrinker, which calls\ndma_resv_lock. This in turn acquires fs_reclaim.\n\nFix this deadlock by using dma_resv_trylock() instead, dropping the\nsubsequently unused passed wait-wound lock \u0027ticket\u0027.\n\nPatchwork: https://patchwork.freedesktop.org/patch/723564/\n[rob: fixup compile errors, replace lockdep splat with somethin\n---truncated---",
"id": "GHSA-3q3c-q46p-rwcg",
"modified": "2026-08-11T18:30:36Z",
"published": "2026-07-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64100"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3392291fc509d8ad6e4ad90f15b0a193f721cbc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/928788566c79046f71a211fc32c115400be76402"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/942968260e61d4a5d7552b20814b6277f9c553df"
}
],
"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-3QFM-27PW-9J46
Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-08-13 12:31In the Linux kernel, the following vulnerability has been resolved:
gpio: shared: fix deadlock on shared proxy's parent removal
Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set") used the mutex embedded in struct gpio_shared_entry to protect the offset field which now can be modified after assignment. The critical section however is too wide and introduced a potential deadlock on the removal of the shared GPIO proxy's parent.
Make the critical section shorter - only protect the offset when it's being read.
While at it: mention the fact that the entry lock is now also used to protect against concurrent access to the offset field in the structure's documentation.
{
"affected": [],
"aliases": [
"CVE-2026-64238"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T16:16:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: shared: fix deadlock on shared proxy\u0027s parent removal\n\nCommit 710abda58055 (\"gpio: shared: call gpio_chip::of_xlate() if set\")\nused the mutex embedded in struct gpio_shared_entry to protect the\noffset field which now can be modified after assignment. The critical\nsection however is too wide and introduced a potential deadlock on the\nremoval of the shared GPIO proxy\u0027s parent.\n\nMake the critical section shorter - only protect the offset when it\u0027s\nbeing read.\n\nWhile at it: mention the fact that the entry lock is now also used to\nprotect against concurrent access to the offset field in the structure\u0027s\ndocumentation.",
"id": "GHSA-3qfm-27pw-9j46",
"modified": "2026-08-13T12:31:09Z",
"published": "2026-07-24T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64238"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1b836607304f71051f9f9dcccf8b5097b86a1fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a554dfcd30dd5e41d1d67387b3bb85cea83e12e1"
}
],
"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-3QHG-RC86-RH99
Vulnerability from github – Published: 2026-01-31 12:30 – Updated: 2026-03-25 21:30In the Linux kernel, the following vulnerability has been resolved:
rust_binder: remove spin_lock() in rust_shrink_free_page()
When forward-porting Rust Binder to 6.18, I neglected to take commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into account, and apparently I did not end up running the shrinker callback when I sanity tested the driver before submission. This leads to crashes like the following:
============================================
WARNING: possible recursive locking detected
6.18.0-mainline-maybe-dirty #1 Tainted: G IO
--------------------------------------------
kswapd0/68 is trying to acquire lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230
but task is already holding lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&l->lock);
lock(&l->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kswapd0/68:
#0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160
#1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
#2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230
To fix this, remove the spin_lock() call from rust_shrink_free_page().
{
"affected": [],
"aliases": [
"CVE-2025-71181"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-31T12:16:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: remove spin_lock() in rust_shrink_free_page()\n\nWhen forward-porting Rust Binder to 6.18, I neglected to take commit\nfb56fdf8b9a2 (\"mm/list_lru: split the lock to per-cgroup scope\") into\naccount, and apparently I did not end up running the shrinker callback\nwhen I sanity tested the driver before submission. This leads to crashes\nlike the following:\n\n\t============================================\n\tWARNING: possible recursive locking detected\n\t6.18.0-mainline-maybe-dirty #1 Tainted: G IO\n\t--------------------------------------------\n\tkswapd0/68 is trying to acquire lock:\n\tffff956000fa18b0 (\u0026l-\u003elock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230\n\n\tbut task is already holding lock:\n\tffff956000fa18b0 (\u0026l-\u003elock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20\n\n\tother info that might help us debug this:\n\t Possible unsafe locking scenario:\n\n\t CPU0\n\t ----\n\t lock(\u0026l-\u003elock);\n\t lock(\u0026l-\u003elock);\n\n\t *** DEADLOCK ***\n\n\t May be due to missing lock nesting notation\n\n\t3 locks held by kswapd0/68:\n\t #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160\n\t #1: ffff956000fa18b0 (\u0026l-\u003elock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20\n\t #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230\n\nTo fix this, remove the spin_lock() call from rust_shrink_free_page().",
"id": "GHSA-3qhg-rc86-rh99",
"modified": "2026-03-25T21:30:24Z",
"published": "2026-01-31T12:30:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71181"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30a98c97f7874031f2e1de19c777ce011143cba4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/361e0ff456a8daf9753c18030533256e4133ce7a"
}
],
"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-3R62-W556-W3C9
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-17 06:33In the Linux kernel, the following vulnerability has been resolved:
dm-integrity: fix a bug if the bio is out of limits
If dm_integrity_check_limits fails, the code would exit with DM_MAPIO_KILL. However, the range would be already locked at this point, and it wouldn't be unlocked, resulting in a deadlock. Let's move the limit check up, so that when it exits, no resources are leaked.
{
"affected": [],
"aliases": [
"CVE-2026-72100"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:21:24Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-integrity: fix a bug if the bio is out of limits\n\nIf dm_integrity_check_limits fails, the code would exit with\nDM_MAPIO_KILL. However, the range would be already locked at this point,\nand it wouldn\u0027t be unlocked, resulting in a deadlock. Let\u0027s move the\nlimit check up, so that when it exits, no resources are leaked.",
"id": "GHSA-3r62-w556-w3c9",
"modified": "2026-08-17T06:33:09Z",
"published": "2026-08-15T06:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72100"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d1afaa074622859678b1a1e7c1b9c0af74c89b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a266764fadaff8b5c1fe37a186ebf9b09cb953e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa5113e7155f4ea81d2c0303ab5cb272d4b32627"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7989286175f32db8605e767a1a2efc62e894dc8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3RMC-M2PW-8Q44
Vulnerability from github – Published: 2022-05-01 06:58 – Updated: 2024-02-15 21:31The Server Message Block (SMB) driver (MRXSMB.SYS) in Microsoft Windows 2000 SP4, XP SP1 and SP2, and Server 2003 SP1 and earlier allows local users to cause a denial of service (hang) by calling the MrxSmbCscIoctlCloseForCopyChunk with the file handle of the shadow device, which results in a deadlock, aka the "SMB Invalid Handle Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2006-2374"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-06-13T19:06:00Z",
"severity": "LOW"
},
"details": "The Server Message Block (SMB) driver (MRXSMB.SYS) in Microsoft Windows 2000 SP4, XP SP1 and SP2, and Server 2003 SP1 and earlier allows local users to cause a denial of service (hang) by calling the MrxSmbCscIoctlCloseForCopyChunk with the file handle of the shadow device, which results in a deadlock, aka the \"SMB Invalid Handle Vulnerability.\"",
"id": "GHSA-3rmc-m2pw-8q44",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T06:58:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-2374"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2006/ms06-030"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/26830"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1827"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1841"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1850"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1979"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A2030"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A2060"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/20635"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1016288"
},
{
"type": "WEB",
"url": "http://www.idefense.com/intelligence/vulnerabilities/display.php?id=409"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/26439"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/18357"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2006/2327"
}
],
"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-3VVP-54WC-F6JR
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback
SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using smp_cond_load_acquire() until the target CPU's kick_sync advances. Because the irq_work runs in hardirq context, the waiting CPU cannot reschedule and its own kick_sync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.
Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to force the CPU through do_pick_task_scx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the sched_core_balance() pattern, so the CPU can process IPIs while waiting. The local CPU's kick_sync is advanced on entry to do_pick_task_scx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.
{
"affected": [],
"aliases": [
"CVE-2026-43326"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback\n\nSCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using\nsmp_cond_load_acquire() until the target CPU\u0027s kick_sync advances. Because\nthe irq_work runs in hardirq context, the waiting CPU cannot reschedule and\nits own kick_sync never advances. If multiple CPUs form a wait cycle, all\nCPUs deadlock.\n\nReplace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to\nforce the CPU through do_pick_task_scx(), which queues a balance callback\nto perform the wait. The balance callback drops the rq lock and enables\nIRQs following the sched_core_balance() pattern, so the CPU can process\nIPIs while waiting. The local CPU\u0027s kick_sync is advanced on entry to\ndo_pick_task_scx() and continuously during the wait, ensuring any CPU that\nstarts waiting for us sees the advancement and cannot form cyclic\ndependencies.",
"id": "GHSA-3vvp-54wc-f6jr",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43326"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/415cb193bb9736f0e830286c72a6fa8eb2a9cc5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3a7903f65cf4c7fb0477eb0f8b94f326a47fe54"
}
],
"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-3W6Q-RQW9-H6QX
Vulnerability from github – Published: 2025-11-12 21:31 – Updated: 2025-11-13 18:31An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).
{
"affected": [],
"aliases": [
"CVE-2025-63396"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-12T21:15:52Z",
"severity": "LOW"
},
"details": "An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).",
"id": "GHSA-3w6q-rqw9-h6qx",
"modified": "2025-11-13T18:31:03Z",
"published": "2025-11-12T21:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63396"
},
{
"type": "WEB",
"url": "https://github.com/pytorch/pytorch/issues/156563"
},
{
"type": "WEB",
"url": "https://github.com/Daisy2ang"
},
{
"type": "WEB",
"url": "https://github.com/pytorch/pytorch"
},
{
"type": "WEB",
"url": "http://pytorch.com"
}
],
"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"
}
]
}
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.