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.
692 vulnerabilities reference this CWE, most recent first.
GHSA-23PX-9798-3X5C
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove unreasonable unlock in ocfs2_read_blocks
Patch series "Misc fixes for ocfs2_read_blocks", v5.
This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix.
This patch (of 2):
There was a lock release before exiting, so remove the unreasonable unlock.
{
"affected": [],
"aliases": [
"CVE-2024-49965"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: remove unreasonable unlock in ocfs2_read_blocks\n\nPatch series \"Misc fixes for ocfs2_read_blocks\", v5.\n\nThis series contains 2 fixes for ocfs2_read_blocks(). The first patch fix\nthe issue reported by syzbot, which detects bad unlock balance in\nocfs2_read_blocks(). The second patch fixes an issue reported by Heming\nZhao when reviewing above fix.\n\n\nThis patch (of 2):\n\nThere was a lock release before exiting, so remove the unreasonable unlock.",
"id": "GHSA-23px-9798-3x5c",
"modified": "2025-11-04T00:31:43Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39a88623af3f1c686bf6db1e677ed865ffe6fccc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f1ca6ba5452d53c598a45d21267a2c0c221eef3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5245f109b4afb6595360d4c180d483a6d2009a59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81aba693b129e82e11bb54f569504d943d018de9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84543da867c967edffd5065fa910ebf56aaae49d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9753bcb17b36c9add9b32c61766ddf8d2d161911"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c03a82b4a0c935774afa01fd6d128b444fd930a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df4f20fc3673cee11abf2c571987a95733cb638d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f55a33fe0fb5274ef185fd61947cf142138958af"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-23X8-G5MH-PHMC
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.
{
"affected": [],
"aliases": [
"CVE-2024-35997"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\n\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\n\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\n\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\n\nDelete this unnecessary flag.",
"id": "GHSA-23x8-g5mh-phmc",
"modified": "2026-05-12T12:31:52Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"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-24HJ-MV6M-7HW4
Vulnerability from github – Published: 2022-04-30 18:16 – Updated: 2024-02-15 21:31ZoneAlarm and ZoneAlarm Pro allows a local attacker to cause a denial of service by running a trojan to initialize a ZoneAlarm mutex object which prevents ZoneAlarm from starting.
{
"affected": [],
"aliases": [
"CVE-2001-0682"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2001-08-29T04:00:00Z",
"severity": "LOW"
},
"details": "ZoneAlarm and ZoneAlarm Pro allows a local attacker to cause a denial of service by running a trojan to initialize a ZoneAlarm mutex object which prevents ZoneAlarm from starting.",
"id": "GHSA-24hj-mv6m-7hw4",
"modified": "2024-02-15T21:31:22Z",
"published": "2022-04-30T18:16:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2001-0682"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/5821"
},
{
"type": "WEB",
"url": "http://marc.info/?l=ntbugtraq\u0026m=97818917222992\u0026w=2"
}
],
"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-2595-73WG-WGRP
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report:
- j1939_socks_lock
- active_session_list_lock
- sk_session_queue_lock
A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock.
NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase.
[mkl: remove unrelated newline change]
{
"affected": [],
"aliases": [
"CVE-2023-52638"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: prevent deadlock by changing j1939_socks_lock to rwlock\n\nThe following 3 locks would race against each other, causing the\ndeadlock situation in the Syzbot bug report:\n\n- j1939_socks_lock\n- active_session_list_lock\n- sk_session_queue_lock\n\nA reasonable fix is to change j1939_socks_lock to an rwlock, since in\nthe rare situations where a write lock is required for the linked list\nthat j1939_socks_lock is protecting, the code does not attempt to\nacquire any more locks. This would break the circular lock dependency,\nwhere, for example, the current thread already locks j1939_socks_lock\nand attempts to acquire sk_session_queue_lock, and at the same time,\nanother thread attempts to acquire j1939_socks_lock while holding\nsk_session_queue_lock.\n\nNOTE: This patch along does not fix the unregister_netdevice bug\nreported by Syzbot; instead, it solves a deadlock situation to prepare\nfor one or more further patches to actually fix the Syzbot bug, which\nappears to be a reference counting problem within the j1939 codebase.\n\n[mkl: remove unrelated newline change]",
"id": "GHSA-2595-73wg-wgrp",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52638"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf"
}
],
"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-269X-4F35-GF3H
Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
exfat: fix potential deadlock on __exfat_get_dentry_set
When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur.
CPU0 CPU1
---- ----
kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock)
To fix this, let's allocate bh-array with GFP_NOFS.
{
"affected": [],
"aliases": [
"CVE-2024-42315"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T09:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix potential deadlock on __exfat_get_dentry_set\n\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u003es_lock between the two processes may occur.\n\n CPU0 CPU1\n ---- ----\n kswapd\n balance_pgdat\n lock(fs_reclaim)\n exfat_iterate\n lock(\u0026sbi-\u003es_lock)\n exfat_readdir\n exfat_get_uniname_from_ext_entry\n exfat_get_dentry_set\n __exfat_get_dentry_set\n kmalloc_array\n ...\n lock(fs_reclaim)\n ...\n evict\n exfat_evict_inode\n lock(\u0026sbi-\u003es_lock)\n\nTo fix this, let\u0027s allocate bh-array with GFP_NOFS.",
"id": "GHSA-269x-4f35-gf3h",
"modified": "2025-11-03T21:31:11Z",
"published": "2024-08-17T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42315"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2ea1256c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c052f775ee6ccacd3c97e4cf41a2a657e63d4259"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd1c7858641384191ff7033fb1fc65dfcd559c6f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-26P5-HWVM-HF8M
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
ath11k: Fix frames flush failure caused by deadlock
We are seeing below warnings:
kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0
this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds.
By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings:
kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] _syssendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] _sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49123"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: Fix frames flush failure caused by deadlock\n\nWe are seeing below warnings:\n\nkernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0\nkernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0\nkernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0\n\nthis means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work\nhas no chance to run in 5 seconds.\n\nBy setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing\nATH11K_FLUSH_TIMEOUT to 50 we get below warnings:\n\nkernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.\nkernel: [ 120.763169] Not tainted 5.10.90 #12\nkernel: [ 120.763177] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\nkernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0\nkernel: [ 120.763201] Call Trace:\nkernel: [ 120.763214] __schedule+0x785/0x12fa\nkernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb\nkernel: [ 120.763242] schedule+0x7e/0xa1\nkernel: [ 120.763253] schedule_timeout+0x98/0xfe\nkernel: [ 120.763266] ? run_local_timers+0x4a/0x4a\nkernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]\nkernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e\nkernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2\nkernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763802] ? genl_rcv+0x36/0x36\nkernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7\nkernel: [ 120.763829] genl_rcv+0x28/0x36\nkernel: [ 120.763840] netlink_unicast+0x179/0x24b\nkernel: [ 120.763854] netlink_sendmsg+0x393/0x401\nkernel: [ 120.763872] sock_sendmsg+0x72/0x76\nkernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6\nkernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2\nkernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1\nkernel: [ 120.763940] __sys_sendmsg+0x85/0xbf\nkernel: [ 120.763956] do_syscall_64+0x43/0x55\nkernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9\nkernel: [ 120.763977] RIP: 0033:0x79089f3fcc83\nkernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nkernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83\nkernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009\nkernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000\nkernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980\nkernel: [ 120.764032] R13: 00007ffe604\n---truncated---",
"id": "GHSA-26p5-hwvm-hf8m",
"modified": "2025-03-14T00:30:49Z",
"published": "2025-03-14T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49123"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/261b07519518bd14cb168b287b17e1d195f8d0c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33e723dc054edfc94da90eecca3b72cb424ce4a3"
}
],
"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-276P-5GR8-Q5FQ
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-27 21:32In the Linux kernel, the following vulnerability has been resolved:
mptcp: init: protect sched with rcu_read_lock
Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created:
============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted
net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176.
stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfxsyssocket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.
{
"affected": [],
"aliases": [
"CVE-2024-53047"
],
"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\nmptcp: init: protect sched with rcu_read_lock\n\nEnabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT\ncreates this splat when an MPTCP socket is created:\n\n =============================\n WARNING: suspicious RCU usage\n 6.12.0-rc2+ #11 Not tainted\n -----------------------------\n net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n no locks held by mptcp_connect/176.\n\n stack backtrace:\n CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11\n Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl (lib/dump_stack.c:123)\n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)\n mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7))\n mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1))\n ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28)\n inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386)\n ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1))\n __sock_create (net/socket.c:1576)\n __sys_socket (net/socket.c:1671)\n ? __pfx___sys_socket (net/socket.c:1712)\n ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1))\n __x64_sys_socket (net/socket.c:1728)\n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nThat\u0027s because when the socket is initialised, rcu_read_lock() is not\nused despite the explicit comment written above the declaration of\nmptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the\nwarning.",
"id": "GHSA-276p-5gr8-q5fq",
"modified": "2024-11-27T21:32:43Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3deb12c788c385e17142ce6ec50f769852fcec65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/494eb22f9a7bd03783e60595a57611c209175f1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb8b81ad3e893a6d18dcdd3754cc2ea2a42c0136"
}
],
"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-27G4-CRVM-H7GQ
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-09-05 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock held.
Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display.
Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184
{
"affected": [],
"aliases": [
"CVE-2022-48826"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: Fix deadlock on DSI device attach error\n\nDSI device attach to DSI host will be done with host device\u0027s lock\nheld.\n\nUn-registering host in \"device attach\" error path (ex: probe retry)\nwill result in deadlock with below call trace and non operational\nDSI display.\n\nStartup Call trace:\n[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8\n[ 35.043048] mutex_lock_nested+0x7c/0xc8\n[ 35.043060] device_del+0x4c/0x3e8\n[ 35.043075] device_unregister+0x20/0x40\n[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28\n[ 35.043093] device_for_each_child+0x68/0xb0\n[ 35.043105] mipi_dsi_host_unregister+0x40/0x90\n[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]\n[ 35.043199] mipi_dsi_attach+0x30/0x48\n[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]\n[ 35.043225] mipi_dsi_drv_probe+0x28/0x38\n[ 35.043234] really_probe+0xc0/0x318\n[ 35.043244] __driver_probe_device+0x80/0xe8\n[ 35.043254] driver_probe_device+0xb8/0x118\n[ 35.043263] __device_attach_driver+0x98/0xe8\n[ 35.043273] bus_for_each_drv+0x84/0xd8\n[ 35.043281] __device_attach+0xf0/0x150\n[ 35.043290] device_initial_probe+0x1c/0x28\n[ 35.043300] bus_probe_device+0xa4/0xb0\n[ 35.043308] deferred_probe_work_func+0xa0/0xe0\n[ 35.043318] process_one_work+0x254/0x700\n[ 35.043330] worker_thread+0x4c/0x448\n[ 35.043339] kthread+0x19c/0x1a8\n[ 35.043348] ret_from_fork+0x10/0x20\n\nShutdown Call trace:\n[ 365.565417] Call trace:\n[ 365.565423] __switch_to+0x148/0x200\n[ 365.565452] __schedule+0x340/0x9c8\n[ 365.565467] schedule+0x48/0x110\n[ 365.565479] schedule_timeout+0x3b0/0x448\n[ 365.565496] wait_for_completion+0xac/0x138\n[ 365.565509] __flush_work+0x218/0x4e0\n[ 365.565523] flush_work+0x1c/0x28\n[ 365.565536] wait_for_device_probe+0x68/0x158\n[ 365.565550] device_shutdown+0x24/0x348\n[ 365.565561] kernel_restart_prepare+0x40/0x50\n[ 365.565578] kernel_restart+0x20/0x70\n[ 365.565591] __do_sys_reboot+0x10c/0x220\n[ 365.565605] __arm64_sys_reboot+0x2c/0x38\n[ 365.565619] invoke_syscall+0x4c/0x110\n[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120\n[ 365.565648] do_el0_svc+0x2c/0x90\n[ 365.565661] el0_svc+0x4c/0xf0\n[ 365.565671] el0t_64_sync_handler+0x90/0xb8\n[ 365.565682] el0t_64_sync+0x180/0x184",
"id": "GHSA-27g4-crvm-h7gq",
"modified": "2024-09-05T21:31:33Z",
"published": "2024-07-16T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48826"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a3d12ab5097b1d045e693412e6b366b7e82031b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/770d1ba9a8201ce9bee0946eb03746449b6f3b80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dddd832f35096fbc5004e3a7e58fb4d2cefb8deb"
}
],
"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-283V-8HG2-53QV
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
There is a deadlock in ieee80211_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
{
"affected": [],
"aliases": [
"CVE-2022-49305"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()\n\nThere is a deadlock in ieee80211_beacons_stop(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | ieee80211_send_beacon()\nieee80211_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | ieee80211_send_beacon_cb()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold ieee-\u003ebeacon_lock in position (1) of thread 1 and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u003ebeacon_lock in position (2) of thread 2.\nAs a result, ieee80211_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.",
"id": "GHSA-283v-8hg2-53qv",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49305"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3"
}
],
"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-28H2-465H-Q5V7
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-16 18:30In the Linux kernel, the following vulnerability has been resolved:
block: Fix potential deadlock while freezing queue and acquiring sysfs_lock
For storing a value to a queue attribute, the queue_attr_store function first freezes the queue (->q_usage_counter(io)) and then acquire ->sysfs_lock. This seems not correct as the usual ordering should be to acquire ->sysfs_lock before freezing the queue. This incorrect ordering causes the following lockdep splat which we are able to reproduce always simply by accessing /sys/kernel/debug file using ls command:
[ 57.597146] WARNING: possible circular locking dependency detected [ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W [ 57.597162] ------------------------------------------------------ [ 57.597168] ls/4605 is trying to acquire lock: [ 57.597176] c00000003eb56710 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0 [ 57.597200] but task is already holding lock: [ 57.597207] c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4 [ 57.597226] which lock already depends on the new lock.
[ 57.597233] the existing dependency chain (in reverse order) is: [ 57.597241] -> #5 (&sb->s_type->i_mutex_key#3){++++}-{4:4}: [ 57.597255] down_write+0x6c/0x18c [ 57.597264] start_creating+0xb4/0x24c [ 57.597274] debugfs_create_dir+0x2c/0x1e8 [ 57.597283] blk_register_queue+0xec/0x294 [ 57.597292] add_disk_fwnode+0x2e4/0x548 [ 57.597302] brd_alloc+0x2c8/0x338 [ 57.597309] brd_init+0x100/0x178 [ 57.597317] do_one_initcall+0x88/0x3e4 [ 57.597326] kernel_init_freeable+0x3cc/0x6e0 [ 57.597334] kernel_init+0x34/0x1cc [ 57.597342] ret_from_kernel_user_thread+0x14/0x1c [ 57.597350] -> #4 (&q->debugfs_mutex){+.+.}-{4:4}: [ 57.597362] __mutex_lock+0xfc/0x12a0 [ 57.597370] blk_register_queue+0xd4/0x294 [ 57.597379] add_disk_fwnode+0x2e4/0x548 [ 57.597388] brd_alloc+0x2c8/0x338 [ 57.597395] brd_init+0x100/0x178 [ 57.597402] do_one_initcall+0x88/0x3e4 [ 57.597410] kernel_init_freeable+0x3cc/0x6e0 [ 57.597418] kernel_init+0x34/0x1cc [ 57.597426] ret_from_kernel_user_thread+0x14/0x1c [ 57.597434] -> #3 (&q->sysfs_lock){+.+.}-{4:4}: [ 57.597446] __mutex_lock+0xfc/0x12a0 [ 57.597454] queue_attr_store+0x9c/0x110 [ 57.597462] sysfs_kf_write+0x70/0xb0 [ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac [ 57.597480] vfs_write+0x3dc/0x6e8 [ 57.597488] ksys_write+0x84/0x140 [ 57.597495] system_call_exception+0x130/0x360 [ 57.597504] system_call_common+0x160/0x2c4 [ 57.597516] -> #2 (&q->q_usage_counter(io)#21){++++}-{0:0}: [ 57.597530] __submit_bio+0x5ec/0x828 [ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0 [ 57.597547] iomap_readahead+0x2a0/0x448 [ 57.597556] xfs_vm_readahead+0x28/0x3c [ 57.597564] read_pages+0x88/0x41c [ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8 [ 57.597580] filemap_get_pages+0x188/0x984 [ 57.597588] filemap_read+0x13c/0x4bc [ 57.597596] xfs_file_buffered_read+0x88/0x17c [ 57.597605] xfs_file_read_iter+0xac/0x158 [ 57.597614] vfs_read+0x2d4/0x3b4 [ 57.597622] ksys_read+0x84/0x144 [ 57.597629] system_call_exception+0x130/0x360 [ 57.597637] system_call_common+0x160/0x2c4 [ 57.597647] -> #1 (mapping.invalidate_lock#2){++++}-{4:4}: [ 57.597661] down_read+0x6c/0x220 [ 57.597669] filemap_fault+0x870/0x100c [ 57.597677] xfs_filemap_fault+0xc4/0x18c [ 57.597684] __do_fault+0x64/0x164 [ 57.597693] __handle_mm_fault+0x1274/0x1dac [ 57.597702] handle_mm_fault+0x248/0x48 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-53689"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix potential deadlock while freezing queue and acquiring sysfs_lock\n\nFor storing a value to a queue attribute, the queue_attr_store function\nfirst freezes the queue (-\u003eq_usage_counter(io)) and then acquire\n-\u003esysfs_lock. This seems not correct as the usual ordering should be to\nacquire -\u003esysfs_lock before freezing the queue. This incorrect ordering\ncauses the following lockdep splat which we are able to reproduce always\nsimply by accessing /sys/kernel/debug file using ls command:\n\n[ 57.597146] WARNING: possible circular locking dependency detected\n[ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W\n[ 57.597162] ------------------------------------------------------\n[ 57.597168] ls/4605 is trying to acquire lock:\n[ 57.597176] c00000003eb56710 (\u0026mm-\u003emmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0\n[ 57.597200]\n but task is already holding lock:\n[ 57.597207] c0000018e27c6810 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4\n[ 57.597226]\n which lock already depends on the new lock.\n\n[ 57.597233]\n the existing dependency chain (in reverse order) is:\n[ 57.597241]\n -\u003e #5 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}:\n[ 57.597255] down_write+0x6c/0x18c\n[ 57.597264] start_creating+0xb4/0x24c\n[ 57.597274] debugfs_create_dir+0x2c/0x1e8\n[ 57.597283] blk_register_queue+0xec/0x294\n[ 57.597292] add_disk_fwnode+0x2e4/0x548\n[ 57.597302] brd_alloc+0x2c8/0x338\n[ 57.597309] brd_init+0x100/0x178\n[ 57.597317] do_one_initcall+0x88/0x3e4\n[ 57.597326] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597334] kernel_init+0x34/0x1cc\n[ 57.597342] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597350]\n -\u003e #4 (\u0026q-\u003edebugfs_mutex){+.+.}-{4:4}:\n[ 57.597362] __mutex_lock+0xfc/0x12a0\n[ 57.597370] blk_register_queue+0xd4/0x294\n[ 57.597379] add_disk_fwnode+0x2e4/0x548\n[ 57.597388] brd_alloc+0x2c8/0x338\n[ 57.597395] brd_init+0x100/0x178\n[ 57.597402] do_one_initcall+0x88/0x3e4\n[ 57.597410] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597418] kernel_init+0x34/0x1cc\n[ 57.597426] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597434]\n -\u003e #3 (\u0026q-\u003esysfs_lock){+.+.}-{4:4}:\n[ 57.597446] __mutex_lock+0xfc/0x12a0\n[ 57.597454] queue_attr_store+0x9c/0x110\n[ 57.597462] sysfs_kf_write+0x70/0xb0\n[ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac\n[ 57.597480] vfs_write+0x3dc/0x6e8\n[ 57.597488] ksys_write+0x84/0x140\n[ 57.597495] system_call_exception+0x130/0x360\n[ 57.597504] system_call_common+0x160/0x2c4\n[ 57.597516]\n -\u003e #2 (\u0026q-\u003eq_usage_counter(io)#21){++++}-{0:0}:\n[ 57.597530] __submit_bio+0x5ec/0x828\n[ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0\n[ 57.597547] iomap_readahead+0x2a0/0x448\n[ 57.597556] xfs_vm_readahead+0x28/0x3c\n[ 57.597564] read_pages+0x88/0x41c\n[ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8\n[ 57.597580] filemap_get_pages+0x188/0x984\n[ 57.597588] filemap_read+0x13c/0x4bc\n[ 57.597596] xfs_file_buffered_read+0x88/0x17c\n[ 57.597605] xfs_file_read_iter+0xac/0x158\n[ 57.597614] vfs_read+0x2d4/0x3b4\n[ 57.597622] ksys_read+0x84/0x144\n[ 57.597629] system_call_exception+0x130/0x360\n[ 57.597637] system_call_common+0x160/0x2c4\n[ 57.597647]\n -\u003e #1 (mapping.invalidate_lock#2){++++}-{4:4}:\n[ 57.597661] down_read+0x6c/0x220\n[ 57.597669] filemap_fault+0x870/0x100c\n[ 57.597677] xfs_filemap_fault+0xc4/0x18c\n[ 57.597684] __do_fault+0x64/0x164\n[ 57.597693] __handle_mm_fault+0x1274/0x1dac\n[ 57.597702] handle_mm_fault+0x248/0x48\n---truncated---",
"id": "GHSA-28h2-465h-q5v7",
"modified": "2025-01-16T18:30:59Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be26ba96421ab0a8fa2055ccf7db7832a13c44d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1a494df8350da2e673618627cb392a8669825dd"
}
],
"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.