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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-F834-HVGH-G5V9
Vulnerability from github – Published: 2024-04-10 21:30 – Updated: 2024-11-05 00:31In the Linux kernel, the following vulnerability has been resolved:
scsi: core: sysfs: Fix hang when device state is set via sysfs
This fixes a regression added with:
commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device")
The problem is that after iSCSI recovery, iscsid will call into the kernel to set the dev's state to running, and with that patch we now call scsi_rescan_device() with the state_mutex held. If the SCSI error handler thread is just starting to test the device in scsi_send_eh_cmnd() then it's going to try to grab the state_mutex.
We are then stuck, because when scsi_rescan_device() tries to send its I/O scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery() which will return true (the host state is still in recovery) and I/O will just be requeued. scsi_send_eh_cmnd() will then never be able to grab the state_mutex to finish error handling.
To prevent the deadlock move the rescan-related code to after we drop the state_mutex.
This also adds a check for if we are already in the running state. This prevents extra scans and helps the iscsid case where if the transport class has already onlined the device during its recovery process then we don't need userspace to do it again plus possibly block that daemon.
{
"affected": [],
"aliases": [
"CVE-2021-47192"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T19:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: sysfs: Fix hang when device state is set via sysfs\n\nThis fixes a regression added with:\n\ncommit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after\nofflinining device\")\n\nThe problem is that after iSCSI recovery, iscsid will call into the kernel\nto set the dev\u0027s state to running, and with that patch we now call\nscsi_rescan_device() with the state_mutex held. If the SCSI error handler\nthread is just starting to test the device in scsi_send_eh_cmnd() then it\u0027s\ngoing to try to grab the state_mutex.\n\nWe are then stuck, because when scsi_rescan_device() tries to send its I/O\nscsi_queue_rq() calls -\u003e scsi_host_queue_ready() -\u003e scsi_host_in_recovery()\nwhich will return true (the host state is still in recovery) and I/O will\njust be requeued. scsi_send_eh_cmnd() will then never be able to grab the\nstate_mutex to finish error handling.\n\nTo prevent the deadlock move the rescan-related code to after we drop the\nstate_mutex.\n\nThis also adds a check for if we are already in the running state. This\nprevents extra scans and helps the iscsid case where if the transport class\nhas already onlined the device during its recovery process then we don\u0027t\nneed userspace to do it again plus possibly block that daemon.",
"id": "GHSA-f834-hvgh-g5v9",
"modified": "2024-11-05T00:31:26Z",
"published": "2024-04-10T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47192"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F94P-FCWW-CPFJ
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-24 21:31In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock in error path of mcp251x_open
The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish.
This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path.
To solve this issue move the call to free_irq() after the lock is
released. Setting priv->force_quit = 1 beforehand ensure that the IRQ
handler will exit right away once it acquired the lock.
{
"affected": [],
"aliases": [
"CVE-2026-23357"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcp251x: fix deadlock in error path of mcp251x_open\n\nThe mcp251x_open() function call free_irq() in its error path with the\nmpc_lock mutex held. But if an interrupt already occurred the\ninterrupt handler will be waiting for the mpc_lock and free_irq() will\ndeadlock waiting for the handler to finish.\n\nThis issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can:\nmcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but\nfor the error path.\n\nTo solve this issue move the call to free_irq() after the lock is\nreleased. Setting `priv-\u003eforce_quit = 1` beforehand ensure that the IRQ\nhandler will exit right away once it acquired the lock.",
"id": "GHSA-f94p-fcww-cpfj",
"modified": "2026-04-24T21:31:56Z",
"published": "2026-03-25T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23357"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/256f0cff6e946c570392bda1d01a65e789a7afd0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38063cc435b69d56e76f947c10d336fcb2953508"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/416c18ecddafab0ed09be1e7b9d2f448f3d4db16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/739454057572cb0948658d1142f3fa2c6966465c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab3f894de216f4a62adc3b57e9191888cbf26885"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b73832292cd914e87a55e863ba4413a907e7db6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d27f12c3f5e85efc479896af4a69eccb37f75e8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e728f444c913a91d290d1824b4770780bbd6378e"
}
],
"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-F95Q-FWQ6-MX8W
Vulnerability from github – Published: 2024-08-21 00:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a deadlock in dma buf fence polling
Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock.
dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called.
Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-43863"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T00:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\n\nIntroduce a version of the fence ops that on release doesn\u0027t remove\nthe fence from the pending list, and thus doesn\u0027t require a lock to\nfix poll-\u003efence wait-\u003efence unref deadlocks.\n\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\n\ndma buf polling cb unrefs a fence after it\u0027s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0027s held by the wait from which it\nwas called.\n\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.",
"id": "GHSA-f95q-fwq6-mx8w",
"modified": "2025-11-04T00:31:17Z",
"published": "2024-08-21T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9908dc0d2ef0e4aec8a242c098455729c0e2f017"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f"
},
{
"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/10/msg00007.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-FC34-92XQ-43PM
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-03 09:33In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix soft lockup in mptcp_recvmsg()
syzbot reported a soft lockup in mptcp_recvmsg() [0].
When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not removed from the sk_receive_queue. This causes sk_wait_data() to always find available data and never perform actual waiting, leading to a soft lockup.
Fix this by adding a 'last' parameter to track the last peeked skb. This allows sk_wait_data() to make informed waiting decisions and prevent infinite loops when MSG_PEEK is used.
[0]: watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963] Modules linked in: CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_wait_data+0x15/0x190 Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb <48> 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101 R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18 R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000 FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0 Call Trace: mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329 inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891 sock_recvmsg+0x94/0xc0 net/socket.c:1100 __sys_recvfrom+0xb2/0x130 net/socket.c:2256 __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267 do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131 RIP: 0033:0x7f6e386a4a1d Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004 RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0 R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000
{
"affected": [],
"aliases": [
"CVE-2026-43029"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:47Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix soft lockup in mptcp_recvmsg()\n\nsyzbot reported a soft lockup in mptcp_recvmsg() [0].\n\nWhen receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not\nremoved from the sk_receive_queue. This causes sk_wait_data() to always\nfind available data and never perform actual waiting, leading to a soft\nlockup.\n\nFix this by adding a \u0027last\u0027 parameter to track the last peeked skb.\nThis allows sk_wait_data() to make informed waiting decisions and prevent\ninfinite loops when MSG_PEEK is used.\n\n[0]:\nwatchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963]\nModules linked in:\nCPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_wait_data+0x15/0x190\nCode: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb \u003c48\u003e 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b\nRSP: 0018:ffffc90000603ca0 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800\nRBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101\nR10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18\nR13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000\nFS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0\nCall Trace:\n \u003cTASK\u003e\n mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329\n inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891\n sock_recvmsg+0x94/0xc0 net/socket.c:1100\n __sys_recvfrom+0xb2/0x130 net/socket.c:2256\n __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267\n do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131\nRIP: 0033:0x7f6e386a4a1d\nCode: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41\nRSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d\nRDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004\nRBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0\nR13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000\n \u003c/TASK\u003e",
"id": "GHSA-fc34-92xq-43pm",
"modified": "2026-05-03T09:33:10Z",
"published": "2026-05-01T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58b58b9ba89c43914eea90c18928e51852d10c24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5dd8025a49c268ab6b94d978532af3ad341132a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de3c248d1b69eaefa2d5b3da4005936dcf590f1b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FF5R-W44X-RQ6X
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-11 00:30In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Rework long task execution when adding/deleting entries
When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step.
The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel.
{
"affected": [],
"aliases": [
"CVE-2023-53549"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Rework long task execution when adding/deleting entries\n\nWhen adding/deleting large number of elements in one step in ipset, it can\ntake a reasonable amount of time and can result in soft lockup errors. The\npatch 5f7b51bf09ba (\"netfilter: ipset: Limit the maximal range of\nconsecutive elements to add/delete\") tried to fix it by limiting the max\nelements to process at all. However it was not enough, it is still possible\nthat we get hung tasks. Lowering the limit is not reasonable, so the\napproach in this patch is as follows: rely on the method used at resizing\nsets and save the state when we reach a smaller internal batch limit,\nunlock/lock and proceed from the saved state. Thus we can avoid long\ncontinuous tasks and at the same time removed the limit to add/delete large\nnumber of elements in one step.\n\nThe nfnl mutex is held during the whole operation which prevents one to\nissue other ipset commands in parallel.",
"id": "GHSA-ff5r-w44x-rq6x",
"modified": "2026-02-11T00:30:14Z",
"published": "2025-10-04T18:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24a828f5a54bdeca0846526860d72b3766c5fe95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e29dc36bd5e2166b834ceb19990d9e68a734d7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8964cc36ba011dc0e1041131fa2e91fb4c2a811b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1e1521b463968b4eca7163f61fb6cc54d008061"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2"
}
],
"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-FF75-3HC4-J344
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-31 18:31In the Linux kernel, the following vulnerability has been resolved:
pinmux: Use sequential access to access desc->pinmux data
When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.
Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.
Serialize the access to mux related setting with a mutex lock.
cpu0 (process A) cpu1(process B)
pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
if (desc->mux_usecount > 1)
return 0;
desc->mux_owner = owner;
} }
{
"affected": [],
"aliases": [
"CVE-2024-47141"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npinmux: Use sequential access to access desc-\u003epinmux data\n\nWhen two client of the same gpio call pinctrl_select_state() for the\nsame functionality, we are seeing NULL pointer issue while accessing\ndesc-\u003emux_owner.\n\nLet\u0027s say two processes A, B executing in pin_request() for the same pin\nand process A updates the desc-\u003emux_usecount but not yet updated the\ndesc-\u003emux_owner while process B see the desc-\u003emux_usecount which got\nupdated by A path and further executes strcmp and while accessing\ndesc-\u003emux_owner it crashes with NULL pointer.\n\nSerialize the access to mux related setting with a mutex lock.\n\n\tcpu0 (process A)\t\t\tcpu1(process B)\n\npinctrl_select_state() {\t\t pinctrl_select_state() {\n pin_request() {\t\t\t\tpin_request() {\n ...\n\t\t\t\t\t\t ....\n } else {\n desc-\u003emux_usecount++;\n \t\t\t\t\t\tdesc-\u003emux_usecount \u0026\u0026 strcmp(desc-\u003emux_owner, owner)) {\n\n if (desc-\u003emux_usecount \u003e 1)\n return 0;\n desc-\u003emux_owner = owner;\n\n }\t\t\t\t\t\t}",
"id": "GHSA-ff75-3hc4-j344",
"modified": "2025-01-31T18:31:04Z",
"published": "2025-01-11T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47141"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c11e2ec9a780f54982a187ee10ffd1b810715c85"
}
],
"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-FFF7-R5FR-892Q
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 18:31In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix reset error handling
Do not call iavf_close in iavf_reset_task error handling. Doing so can lead to double call of napi_disable, which can lead to deadlock there. Removing VF would lead to iavf_remove task being stuck, because it requires crit_lock, which is held by iavf_close. Call iavf_disable_vf if reset fail, so that driver will clean up remaining invalid resources. During rapid VF resets, HW can fail to setup VF mailbox. Wrong error handling can lead to iavf_remove being stuck with: [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53 ... [ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds. [ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000 [ 5267.190347] Call Trace: [ 5267.190647] [ 5267.190927] __schedule+0x460/0x9f0 [ 5267.191264] schedule+0x44/0xb0 [ 5267.191563] schedule_preempt_disabled+0x14/0x20 [ 5267.191890] __mutex_lock.isra.12+0x6e3/0xac0 [ 5267.192237] ? iavf_remove+0xf9/0x6c0 [iavf] [ 5267.192565] iavf_remove+0x12a/0x6c0 [iavf] [ 5267.192911] ? _raw_spin_unlock_irqrestore+0x1e/0x40 [ 5267.193285] pci_device_remove+0x36/0xb0 [ 5267.193619] device_release_driver_internal+0xc1/0x150 [ 5267.193974] pci_stop_bus_device+0x69/0x90 [ 5267.194361] pci_stop_and_remove_bus_device+0xe/0x20 [ 5267.194735] pci_iov_remove_virtfn+0xba/0x120 [ 5267.195130] sriov_disable+0x2f/0xe0 [ 5267.195506] ice_free_vfs+0x7d/0x2f0 [ice] [ 5267.196056] ? pci_get_device+0x4f/0x70 [ 5267.196496] ice_sriov_configure+0x78/0x1a0 [ice] [ 5267.196995] sriov_numvfs_store+0xfe/0x140 [ 5267.197466] kernfs_fop_write_iter+0x12e/0x1c0 [ 5267.197918] new_sync_write+0x10c/0x190 [ 5267.198404] vfs_write+0x24e/0x2d0 [ 5267.198886] ksys_write+0x5c/0xd0 [ 5267.199367] do_syscall_64+0x3a/0x80 [ 5267.199827] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 5267.200317] RIP: 0033:0x7f5b381205c8 [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8 [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001 [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820 [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0 [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002 [ 5267.206041] [ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019 [ 5267.209623] Call Trace: [ 5267.210569] [ 5267.211480] dump_stack_lvl+0x33/0x42 [ 5267.212472] panic+0x107/0x294 [ 5267.213467] watchdog.cold.8+0xc/0xbb [ 5267.214413] ? proc_dohung_task_timeout_secs+0x30/0x30 [ 5267.215511] kthread+0xf4/0x120 [ 5267.216459] ? kthread_complete_and_exit+0x20/0x20 [ 5267.217505] ret_from_fork+0x22/0x30 [ 5267.218459]
{
"affected": [],
"aliases": [
"CVE-2022-50053"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix reset error handling\n\nDo not call iavf_close in iavf_reset_task error handling. Doing so can\nlead to double call of napi_disable, which can lead to deadlock there.\nRemoving VF would lead to iavf_remove task being stuck, because it\nrequires crit_lock, which is held by iavf_close.\nCall iavf_disable_vf if reset fail, so that driver will clean up\nremaining invalid resources.\nDuring rapid VF resets, HW can fail to setup VF mailbox. Wrong\nerror handling can lead to iavf_remove being stuck with:\n[ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53\n...\n[ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.\n[ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.189764] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000\n[ 5267.190347] Call Trace:\n[ 5267.190647] \u003cTASK\u003e\n[ 5267.190927] __schedule+0x460/0x9f0\n[ 5267.191264] schedule+0x44/0xb0\n[ 5267.191563] schedule_preempt_disabled+0x14/0x20\n[ 5267.191890] __mutex_lock.isra.12+0x6e3/0xac0\n[ 5267.192237] ? iavf_remove+0xf9/0x6c0 [iavf]\n[ 5267.192565] iavf_remove+0x12a/0x6c0 [iavf]\n[ 5267.192911] ? _raw_spin_unlock_irqrestore+0x1e/0x40\n[ 5267.193285] pci_device_remove+0x36/0xb0\n[ 5267.193619] device_release_driver_internal+0xc1/0x150\n[ 5267.193974] pci_stop_bus_device+0x69/0x90\n[ 5267.194361] pci_stop_and_remove_bus_device+0xe/0x20\n[ 5267.194735] pci_iov_remove_virtfn+0xba/0x120\n[ 5267.195130] sriov_disable+0x2f/0xe0\n[ 5267.195506] ice_free_vfs+0x7d/0x2f0 [ice]\n[ 5267.196056] ? pci_get_device+0x4f/0x70\n[ 5267.196496] ice_sriov_configure+0x78/0x1a0 [ice]\n[ 5267.196995] sriov_numvfs_store+0xfe/0x140\n[ 5267.197466] kernfs_fop_write_iter+0x12e/0x1c0\n[ 5267.197918] new_sync_write+0x10c/0x190\n[ 5267.198404] vfs_write+0x24e/0x2d0\n[ 5267.198886] ksys_write+0x5c/0xd0\n[ 5267.199367] do_syscall_64+0x3a/0x80\n[ 5267.199827] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 5267.200317] RIP: 0033:0x7f5b381205c8\n[ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8\n[ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001\n[ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820\n[ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0\n[ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002\n[ 5267.206041] \u003c/TASK\u003e\n[ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks\n[ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019\n[ 5267.209623] Call Trace:\n[ 5267.210569] \u003cTASK\u003e\n[ 5267.211480] dump_stack_lvl+0x33/0x42\n[ 5267.212472] panic+0x107/0x294\n[ 5267.213467] watchdog.cold.8+0xc/0xbb\n[ 5267.214413] ? proc_dohung_task_timeout_secs+0x30/0x30\n[ 5267.215511] kthread+0xf4/0x120\n[ 5267.216459] ? kthread_complete_and_exit+0x20/0x20\n[ 5267.217505] ret_from_fork+0x22/0x30\n[ 5267.218459] \u003c/TASK\u003e",
"id": "GHSA-fff7-r5fr-892q",
"modified": "2025-11-13T18:31:00Z",
"published": "2025-06-18T12:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0828e27971f18ea317710acb228afe6e72606082"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31071173771e079f7bc08dacd61e0db913262fbf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/743dc4377bbac06a6fe44c3c5baf75a49439678a"
}
],
"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-FFQ9-G2VV-386P
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 21:30In the Linux kernel, the following vulnerability has been resolved:
mm: Fix a hmm_range_fault() livelock / starvation problem
If hmm_range_fault() fails a folio_trylock() in do_swap_page, trying to acquire the lock of a device-private folio for migration, to ram, the function will spin until it succeeds grabbing the lock.
However, if the process holding the lock is depending on a work item to be completed, which is scheduled on the same CPU as the spinning hmm_range_fault(), that work item might be starved and we end up in a livelock / starvation situation which is never resolved.
This can happen, for example if the process holding the device-private folio lock is stuck in migrate_device_unmap()->lru_add_drain_all() sinc lru_add_drain_all() requires a short work-item to be run on all online cpus to complete.
A prerequisite for this to happen is: a) Both zone device and system memory folios are considered in migrate_device_unmap(), so that there is a reason to call lru_add_drain_all() for a system memory folio while a folio lock is held on a zone device folio. b) The zone device folio has an initial mapcount > 1 which causes at least one migration PTE entry insertion to be deferred to try_to_migrate(), which can happen after the call to lru_add_drain_all(). c) No or voluntary only preemption.
This all seems pretty unlikely to happen, but indeed is hit by the "xe_exec_system_allocator" igt test.
Resolve this by waiting for the folio to be unlocked if the folio_trylock() fails in do_swap_page().
Rename migration_entry_wait_on_locked() to softleaf_entry_wait_unlock() and update its documentation to indicate the new use-case.
Future code improvements might consider moving the lru_add_drain_all() call in migrate_device_unmap() to be called after all pages have migration entries inserted. That would eliminate also b) above.
v2: - Instead of a cond_resched() in hmm_range_fault(), eliminate the problem by waiting for the folio to be unlocked in do_swap_page() (Alistair Popple, Andrew Morton) v3: - Add a stub migration_entry_wait_on_locked() for the !CONFIG_MIGRATION case. (Kernel Test Robot) v4: - Rename migrate_entry_wait_on_locked() to softleaf_entry_wait_on_locked() and update docs (Alistair Popple) v5: - Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION version of softleaf_entry_wait_on_locked(). - Modify wording around function names in the commit message (Andrew Morton)
(cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)
{
"affected": [],
"aliases": [
"CVE-2026-43404"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: Fix a hmm_range_fault() livelock / starvation problem\n\nIf hmm_range_fault() fails a folio_trylock() in do_swap_page,\ntrying to acquire the lock of a device-private folio for migration,\nto ram, the function will spin until it succeeds grabbing the lock.\n\nHowever, if the process holding the lock is depending on a work\nitem to be completed, which is scheduled on the same CPU as the\nspinning hmm_range_fault(), that work item might be starved and\nwe end up in a livelock / starvation situation which is never\nresolved.\n\nThis can happen, for example if the process holding the\ndevice-private folio lock is stuck in\n migrate_device_unmap()-\u003elru_add_drain_all()\nsinc lru_add_drain_all() requires a short work-item\nto be run on all online cpus to complete.\n\nA prerequisite for this to happen is:\na) Both zone device and system memory folios are considered in\n migrate_device_unmap(), so that there is a reason to call\n lru_add_drain_all() for a system memory folio while a\n folio lock is held on a zone device folio.\nb) The zone device folio has an initial mapcount \u003e 1 which causes\n at least one migration PTE entry insertion to be deferred to\n try_to_migrate(), which can happen after the call to\n lru_add_drain_all().\nc) No or voluntary only preemption.\n\nThis all seems pretty unlikely to happen, but indeed is hit by\nthe \"xe_exec_system_allocator\" igt test.\n\nResolve this by waiting for the folio to be unlocked if the\nfolio_trylock() fails in do_swap_page().\n\nRename migration_entry_wait_on_locked() to\nsoftleaf_entry_wait_unlock() and update its documentation to\nindicate the new use-case.\n\nFuture code improvements might consider moving\nthe lru_add_drain_all() call in migrate_device_unmap() to be\ncalled *after* all pages have migration entries inserted.\nThat would eliminate also b) above.\n\nv2:\n- Instead of a cond_resched() in hmm_range_fault(),\n eliminate the problem by waiting for the folio to be unlocked\n in do_swap_page() (Alistair Popple, Andrew Morton)\nv3:\n- Add a stub migration_entry_wait_on_locked() for the\n !CONFIG_MIGRATION case. (Kernel Test Robot)\nv4:\n- Rename migrate_entry_wait_on_locked() to\n softleaf_entry_wait_on_locked() and update docs (Alistair Popple)\nv5:\n- Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION\n version of softleaf_entry_wait_on_locked().\n- Modify wording around function names in the commit message\n (Andrew Morton)\n\n(cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)",
"id": "GHSA-ffq9-g2vv-386p",
"modified": "2026-05-21T21:30:30Z",
"published": "2026-05-08T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43404"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e6e2fc91d4b9b12ec6e137019532568ebcf2680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94b6d0ba4b640ba23bb6c708a59316e74e5ede63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b570f37a2ce480be26c665345c5514686a8a0274"
}
],
"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-FGCR-GVFF-J4CQ
Vulnerability from github – Published: 2022-05-01 02:14 – Updated: 2024-02-15 21:31Race condition in Linux 2.6, when threads are sharing memory mapping via CLONE_VM (such as linuxthreads and vfork), might allow local users to cause a denial of service (deadlock) by triggering a core dump while waiting for a thread that has just performed an exec.
{
"affected": [],
"aliases": [
"CVE-2005-3106"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-09-30T10:05:00Z",
"severity": "LOW"
},
"details": "Race condition in Linux 2.6, when threads are sharing memory mapping via CLONE_VM (such as linuxthreads and vfork), might allow local users to cause a denial of service (deadlock) by triggering a core dump while waiting for a thread that has just performed an exec.",
"id": "GHSA-fgcr-gvff-j4cq",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T02:14:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-3106"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A9108"
},
{
"type": "WEB",
"url": "http://linux.bkbits.net:8080/linux-2.6/diffs/fs/exec.c%401.156?nav=index.html%7Csrc/%7Csrc/fs%7Chist/fs/exec.c"
},
{
"type": "WEB",
"url": "http://linux.bkbits.net:8080/linux-2.6/diffs/fs/exec.c@1.156?nav=index.html|src/|src/fs|hist/fs/exec.c"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17141"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18056"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18510"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-922"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2006:072"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2006-0101.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/427980/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/15049"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-199-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FGFP-PP34-JXVV
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix possible deadlocks
This fixes possible deadlocks like the following caused by hci_cmd_sync_dequeue causing the destroy function to run:
INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30 __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80 [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth] __mgmt_power_off+0x8d/0x180 [bluetooth] ? _raw_spin_unlock_irq+0x23/0x40 hci_dev_close_sync+0x445/0x5b0 [bluetooth] hci_set_powered_sync+0x149/0x250 [bluetooth] set_powered_sync+0x24/0x60 [bluetooth] hci_cmd_sync_work+0x90/0x150 [bluetooth] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
{
"affected": [],
"aliases": [
"CVE-2024-53207"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible deadlocks\n\nThis fixes possible deadlocks like the following caused by\nhci_cmd_sync_dequeue causing the destroy function to run:\n\n INFO: task kworker/u19:0:143 blocked for more than 120 seconds.\n Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000\n Workqueue: hci0 hci_cmd_sync_work [bluetooth]\n Call Trace:\n \u003cTASK\u003e\n __schedule+0x374/0xaf0\n schedule+0x3c/0xf0\n schedule_preempt_disabled+0x1c/0x30\n __mutex_lock.constprop.0+0x3ef/0x7a0\n __mutex_lock_slowpath+0x13/0x20\n mutex_lock+0x3c/0x50\n mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]\n ? kfree+0x211/0x2a0\n hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]\n ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]\n cmd_complete_rsp+0x26/0x80 [bluetooth]\n mgmt_pending_foreach+0x4d/0x70 [bluetooth]\n __mgmt_power_off+0x8d/0x180 [bluetooth]\n ? _raw_spin_unlock_irq+0x23/0x40\n hci_dev_close_sync+0x445/0x5b0 [bluetooth]\n hci_set_powered_sync+0x149/0x250 [bluetooth]\n set_powered_sync+0x24/0x60 [bluetooth]\n hci_cmd_sync_work+0x90/0x150 [bluetooth]\n process_one_work+0x13e/0x300\n worker_thread+0x2f7/0x420\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x107/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x3d/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e",
"id": "GHSA-fgfp-pp34-jxvv",
"modified": "2025-11-03T21:31:49Z",
"published": "2024-12-27T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5703fb1d85f653e35b327b14de4db7da239e4fd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a25ce9b4af6dc26ee2b9c32d6bd37620bf9739e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a66dfaf18fd61bb75ef8cee83db46b2aadf153d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3f594a3473d6429a0bcf2004cb2885368741b79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cac34e44281f1f1bd842adbbcfe3ef9ff0905111"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.