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.
732 vulnerabilities reference this CWE, most recent first.
GHSA-5X9Q-485P-2V5M
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-10-08 15:32In the Linux kernel, the following vulnerability has been resolved:
bridge: Fix sleep in atomic context in netlink path
Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state).
Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock:
-
Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next.
-
FDB port flushing: Only requires the FDB lock.
-
Multicast attributes: Only require the multicast lock.
-
Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next.
-
Backup port and NHID: Only require RTNL. Read locklessly by the data path.
This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1].
Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes.
[1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356:
0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002)
1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117)
Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) _syssendmsg (net/socket.c:2698) _sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
{
"affected": [],
"aliases": [
"CVE-2026-63989"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: Fix sleep in atomic context in netlink path\n\nSince the introduction of the netlink configuration path for bridge\nports in commit 25c71c75ac87 (\"bridge: bridge port parameters over\nnetlink\"), br_setport() was always called with the bridge lock held\naround it. Back then this decision made sense: The bridge lock protects\nthe STP state of the bridge and its ports and at that time the function\nonly processed three STP related netlink attributes (cost, priority and\nstate).\n\nNowadays, br_setport() processes a lot more attributes and most of them\ndo not need the bridge lock:\n\n* Bridge flags: Only require RTNL. Read locklessly by the data path.\n Annotations can be added in net-next.\n\n* FDB port flushing: Only requires the FDB lock.\n\n* Multicast attributes: Only require the multicast lock.\n\n* Group forward mask: Only requires RTNL. Read locklessly by the data\n path. Annotations can be added in net-next.\n\n* Backup port and NHID: Only require RTNL. Read locklessly by the data\n path.\n\nThis is a problem as the bridge calls dev_set_promiscuity() when certain\nbridge port flags change and this function can sleep since the commit\ncited below, resulting in a splat such as [1].\n\nFix this by reducing the scope of the bridge lock and only take it when\nprocessing the three STP related attributes that require it. This is\nconsistent with the multicast attributes where each attribute acquires\nthe multicast lock instead of having one critical section for all\nrelevant attributes.\n\n[1]\nBUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge\npreempt_count: 201, expected: 0\nRCU nest depth: 0, expected: 0\n2 locks held by bridge/356:\n#0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002)\n#1: ffff888115072d58 (\u0026br-\u003elock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117)\nPreemption disabled at:\n 0x0\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)\n__might_resched.cold (kernel/sched/core.c:9163)\nnetif_rx_mode_run (net/core/dev_addr_lists.c:1262)\nnetif_rx_mode_sync (net/core/dev_addr_lists.c:1428)\ndev_set_promiscuity (net/core/dev_api.c:289)\nbr_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172)\nbr_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747)\nbr_setport (net/bridge/br_netlink.c:1000)\nbr_setlink (net/bridge/br_netlink.c:1118)\nrtnl_bridge_setlink (net/core/rtnetlink.c:5572)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:7005)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4))\n____sys_sendmsg (net/socket.c:2698)\n___sys_sendmsg (net/socket.c:2752)\n__sys_sendmsg (net/socket.c:2784)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)",
"id": "GHSA-5x9q-485p-2v5m",
"modified": "2026-10-08T15:32:32Z",
"published": "2026-07-19T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63989"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5eec4427b89c2fb2beac54920101e55a2f1c0c21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/803d39accfbdf223ccbb49684d5b5069b4c44586"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9c2e609e8397bb57b4d73675f33a99183c4a0bd"
}
],
"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-5XQ3-RMW6-5P48
Vulnerability from github – Published: 2024-04-17 18:31 – Updated: 2025-09-16 18:31In the Linux kernel, the following vulnerability has been resolved:
Revert "drm/amd: flush any delayed gfxoff on suspend entry"
commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again.
Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock.
This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
{
"affected": [],
"aliases": [
"CVE-2024-26916"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T16:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"drm/amd: flush any delayed gfxoff on suspend entry\"\n\ncommit ab4750332dbe (\"drm/amdgpu/sdma5.2: add begin/end_use ring\ncallbacks\") caused GFXOFF control to be used more heavily and the\ncodepath that was removed from commit 0dee72639533 (\"drm/amd: flush any\ndelayed gfxoff on suspend entry\") now can be exercised at suspend again.\n\nUsers report that by using GNOME to suspend the lockscreen trigger will\ncause SDMA traffic and the system can deadlock.\n\nThis reverts commit 0dee726395333fea833eaaf838bc80962df886c8.",
"id": "GHSA-5xq3-rmw6-5p48",
"modified": "2025-09-16T18:31:18Z",
"published": "2024-04-17T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26916"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65158edb0a3a8df23197d52cd24287e39eaf95d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/916361685319098f696b798ef1560f69ed96e934"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/caa2565a2e13899be31f7b1e069e6465d3e2adb0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d855ceb6a5fde668c5431156bc60fae0cc52b764"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff70e6ff6fc2413caf33410af7462d1f584d927e"
}
],
"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-5XQG-J6JP-J9G5
Vulnerability from github – Published: 2025-01-15 15:31 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking
If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...
We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C).
The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fast_io, .disable_locking, etc.
mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex.
However, __setup_irq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock.
It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcp_pinconf_get/set.
mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock().
The accesses to the regmap from mcp23s08_probe_one() do not need additional locking.
In all remaining places where the regmap is accessed, except mcp_pinconf_get/set(), the driver already takes mcp->lock.
This patch adds locking in mcp_pinconf_get/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above.
{
"affected": [],
"aliases": [
"CVE-2024-57889"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-15T13:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking\n\nIf a device uses MCP23xxx IO expander to receive IRQs, the following\nbug can happen:\n\n BUG: sleeping function called from invalid context\n at kernel/locking/mutex.c:283\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...\n preempt_count: 1, expected: 0\n ...\n Call Trace:\n ...\n __might_resched+0x104/0x10e\n __might_sleep+0x3e/0x62\n mutex_lock+0x20/0x4c\n regmap_lock_mutex+0x10/0x18\n regmap_update_bits_base+0x2c/0x66\n mcp23s08_irq_set_type+0x1ae/0x1d6\n __irq_set_trigger+0x56/0x172\n __setup_irq+0x1e6/0x646\n request_threaded_irq+0xb6/0x160\n ...\n\nWe observed the problem while experimenting with a touchscreen driver which\nused MCP23017 IO expander (I2C).\n\nThe regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from\nconcurrent accesses, which is the default for regmaps without .fast_io,\n.disable_locking, etc.\n\nmcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter\nlocks the mutex.\n\nHowever, __setup_irq() locks desc-\u003elock spinlock before calling these\nfunctions. As a result, the system tries to lock the mutex whole holding\nthe spinlock.\n\nIt seems, the internal regmap locks are not needed in this driver at all.\nmcp-\u003elock seems to protect the regmap from concurrent accesses already,\nexcept, probably, in mcp_pinconf_get/set.\n\nmcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under\nchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes\nmcp-\u003elock and enables regmap caching, so that the potentially slow I2C\naccesses are deferred until chip_bus_unlock().\n\nThe accesses to the regmap from mcp23s08_probe_one() do not need additional\nlocking.\n\nIn all remaining places where the regmap is accessed, except\nmcp_pinconf_get/set(), the driver already takes mcp-\u003elock.\n\nThis patch adds locking in mcp_pinconf_get/set() and disables internal\nlocking in the regmap config. Among other things, it fixes the sleeping\nin atomic context described above.",
"id": "GHSA-5xqg-j6jp-j9g5",
"modified": "2025-11-03T21:32:12Z",
"published": "2025-01-15T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57889"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0"
},
{
"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-6246-6GX2-C2HW
Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-03-17 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix lock dependency warning with srcu
====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted
kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0
but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0
-> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0
-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80
-> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0
other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
sync(srcu);
{
"affected": [],
"aliases": [
"CVE-2023-52632"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix lock dependency warning with srcu\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.5.0-kfd-yangp #2289 Not tainted\n------------------------------------------------------\nkworker/0:2/996 is trying to acquire lock:\n (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0\n\nbut task is already holding lock:\n ((work_completion)(\u0026svms-\u003edeferred_list_work)){+.+.}-{0:0}, at:\n\tprocess_one_work+0x211/0x560\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #3 ((work_completion)(\u0026svms-\u003edeferred_list_work)){+.+.}-{0:0}:\n __flush_work+0x88/0x4f0\n svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]\n svm_range_set_attr+0xd6/0x14c0 [amdgpu]\n kfd_ioctl+0x1d1/0x630 [amdgpu]\n __x64_sys_ioctl+0x88/0xc0\n\n-\u003e #2 (\u0026info-\u003elock#2){+.+.}-{3:3}:\n __mutex_lock+0x99/0xc70\n amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]\n restore_process_helper+0x22/0x80 [amdgpu]\n restore_process_worker+0x2d/0xa0 [amdgpu]\n process_one_work+0x29b/0x560\n worker_thread+0x3d/0x3d0\n\n-\u003e #1 ((work_completion)(\u0026(\u0026process-\u003erestore_work)-\u003ework)){+.+.}-{0:0}:\n __flush_work+0x88/0x4f0\n __cancel_work_timer+0x12c/0x1c0\n kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]\n __mmu_notifier_release+0xad/0x240\n exit_mmap+0x6a/0x3a0\n mmput+0x6a/0x120\n do_exit+0x322/0xb90\n do_group_exit+0x37/0xa0\n __x64_sys_exit_group+0x18/0x20\n do_syscall_64+0x38/0x80\n\n-\u003e #0 (srcu){.+.+}-{0:0}:\n __lock_acquire+0x1521/0x2510\n lock_sync+0x5f/0x90\n __synchronize_srcu+0x4f/0x1a0\n __mmu_notifier_release+0x128/0x240\n exit_mmap+0x6a/0x3a0\n mmput+0x6a/0x120\n svm_range_deferred_list_work+0x19f/0x350 [amdgpu]\n process_one_work+0x29b/0x560\n worker_thread+0x3d/0x3d0\n\nother info that might help us debug this:\nChain exists of:\n srcu --\u003e \u0026info-\u003elock#2 --\u003e (work_completion)(\u0026svms-\u003edeferred_list_work)\n\nPossible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock((work_completion)(\u0026svms-\u003edeferred_list_work));\n lock(\u0026info-\u003elock#2);\n\t\t\tlock((work_completion)(\u0026svms-\u003edeferred_list_work));\n sync(srcu);",
"id": "GHSA-6246-6gx2-c2hw",
"modified": "2025-03-17T15:31:37Z",
"published": "2024-04-02T09:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52632"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94"
}
],
"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-625Q-77GV-32CR
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed().
{
"affected": [],
"aliases": [
"CVE-2024-56532"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: us122l: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThe loop of us122l-\u003emmap_count check is dropped as well. The check is\nuseless for the asynchronous operation with *_when_closed().",
"id": "GHSA-625q-77gv-32cr",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/020cbc4d7414f0962004213e2b7bc5cc607e9ec7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2938dd2648522336133c151dd67bb9bf01cbd390"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75f418b249d84021865eaa59515d3ed9b75ce4d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a48bd2184b142c92a4e17eac074c61fcf975bc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b27924dc8d7f8a8c35e521287d4ccb9a006e597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d5c530e4d70f64b1114f2cc29ac690ba7ac4a38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7df09bb348016943f56b09dcaafe221e3f73947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc778ad3e495333eebda36fe91d5b2c93109cc16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf0aa35a7cb8602cccf2387712114e836f65c154"
},
{
"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-62F3-XHHG-6P74
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-18 21:32In the Linux kernel, the following vulnerability has been resolved:
s390/mm: Fix in_atomic() handling in do_secure_storage_access()
Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off.
It is not allowed to take the mmap_lock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page).
{
"affected": [],
"aliases": [
"CVE-2025-38359"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Fix in_atomic() handling in do_secure_storage_access()\n\nKernel user spaces accesses to not exported pages in atomic context\nincorrectly try to resolve the page fault.\nWith debug options enabled call traces like this can be seen:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39\npreempt_count: 1, expected: 0\nRCU nest depth: 0, expected: 0\nINFO: lockdep is turned off.\nPreemption disabled at:\n[\u003c00000383ea47cfa2\u003e] copy_page_from_iter_atomic+0xa2/0x8a0\nCPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39\nTainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT\nTainted: [W]=WARN\nHardware name: IBM 3931 A01 703 (LPAR)\nCall Trace:\n [\u003c00000383e990d282\u003e] dump_stack_lvl+0xa2/0xe8\n [\u003c00000383e99bf152\u003e] __might_resched+0x292/0x2d0\n [\u003c00000383eaa7c374\u003e] down_read+0x34/0x2d0\n [\u003c00000383e99432f8\u003e] do_secure_storage_access+0x108/0x360\n [\u003c00000383eaa724b0\u003e] __do_pgm_check+0x130/0x220\n [\u003c00000383eaa842e4\u003e] pgm_check_handler+0x114/0x160\n [\u003c00000383ea47d028\u003e] copy_page_from_iter_atomic+0x128/0x8a0\n([\u003c00000383ea47d016\u003e] copy_page_from_iter_atomic+0x116/0x8a0)\n [\u003c00000383e9c45eae\u003e] generic_perform_write+0x16e/0x310\n [\u003c00000383e9eb87f4\u003e] ext4_buffered_write_iter+0x84/0x160\n [\u003c00000383e9da0de4\u003e] vfs_write+0x1c4/0x460\n [\u003c00000383e9da123c\u003e] ksys_write+0x7c/0x100\n [\u003c00000383eaa7284e\u003e] __do_syscall+0x15e/0x280\n [\u003c00000383eaa8417e\u003e] system_call+0x6e/0x90\nINFO: lockdep is turned off.\n\nIt is not allowed to take the mmap_lock while in atomic context. Therefore\nhandle such a secure storage access fault as if the accessed page is not\nmapped: the uaccess function will return -EFAULT, and the caller has to\ndeal with this. Usually this means that the access is retried in process\ncontext, which allows to resolve the page fault (or in this case export the\npage).",
"id": "GHSA-62f3-xhhg-6p74",
"modified": "2025-11-18T21:32:29Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38359"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11709abccf93b08adde95ef313c300b0d4bc28f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2e317dfd2d1fe416c77315d17c5d57dbe374915"
}
],
"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-62JP-4QC2-X9XX
Vulnerability from github – Published: 2022-05-01 02:21 – Updated: 2024-02-15 21:31The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.
{
"affected": [],
"aliases": [
"CVE-2005-3847"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-11-27T00:03:00Z",
"severity": "MODERATE"
},
"details": "The handle_stop_signal function in signal.c in Linux kernel 2.6.11 up to other versions before 2.6.13 and 2.6.12.6 allows local users to cause a denial of service (deadlock) by sending a SIGKILL to a real-time threaded process while it is performing a core dump.",
"id": "GHSA-62jp-4qc2-x9xx",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T02:21:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-3847"
},
{
"type": "WEB",
"url": "http://lists.suse.de/archive/suse-security-announce/2006-Feb/0010.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112430346613450\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=112508422716574\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19038"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/19374"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2006/dsa-1017"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git%3Ba=blob%3Bh=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5%3Bhb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd%3Bf=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=blob;h=f6cc7e101c49f356e4c4df5cca1ff352a0f01dd5;hb=9c5fcb99af7c157be45e9d53aeb857ded5211fcd;f=2.6.12.6/nptl-signal-delivery-deadlock-fix.patch"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commitdiff%3Bh=dd12f48d4e8774415b528d3991ae47c28f26e1ac%3Bhp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dd12f48d4e8774415b528d3991ae47c28f26e1ac;hp=ade6648b3b11a5d81f6f28135193ab6d85d621db"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/16856"
}
],
"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-637R-5W8J-MJG6
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2026-04-18 09:30In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: signal scheduled fence when kill job
When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared.
This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.
{
"affected": [],
"aliases": [
"CVE-2025-38436"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T15:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: signal scheduled fence when kill job\n\nWhen an entity from application B is killed, drm_sched_entity_kill()\nremoves all jobs belonging to that entity through\ndrm_sched_entity_kill_jobs_work(). If application A\u0027s job depends on a\nscheduled fence from application B\u0027s job, and that fence is not properly\nsignaled during the killing process, application A\u0027s dependency cannot be\ncleared.\n\nThis leads to application A hanging indefinitely while waiting for a\ndependency that will never be resolved. Fix this issue by ensuring that\nscheduled fences are properly signaled when an entity is killed, allowing\ndependent applications to continue execution.",
"id": "GHSA-637r-5w8j-mjg6",
"modified": "2026-04-18T09:30:16Z",
"published": "2025-07-25T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38436"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/471db2c2d4f80ee94225a1ef246e4f5011733e50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8342127a8a65b0673863b106ce32b79c91ae3270"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa382a8b6ed483e9812d0e63b6d1bdcba0186f29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aefd0a935625165a6ca36d0258d2d053901555df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5734f9bab6f0d40577ad0633af4090a5fda2407"
}
],
"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-63CM-3458-95CR
Vulnerability from github – Published: 2024-03-25 12:30 – Updated: 2025-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
tipc: wait and exit until all work queues are done
On some host, a crash could be triggered simply by repeating these commands several times:
# modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc
[] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40
When removing the TIPC module, the UDP tunnel sock will be delayed to release in a work queue as sock_release() can't be done in rtnl_lock(). If the work queue is schedule to run after the TIPC module is removed, kernel will crash as the work queue function cleanup_beareri() code no longer exists when trying to invoke it.
To fix it, this patch introduce a member wq_count in tipc_net to track the numbers of work queues in schedule, and wait and exit until all work queues are done in tipc_exit_net().
{
"affected": [],
"aliases": [
"CVE-2021-47163"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-25T10:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: wait and exit until all work queues are done\n\nOn some host, a crash could be triggered simply by repeating these\ncommands several times:\n\n # modprobe tipc\n # tipc bearer enable media udp name UDP1 localip 127.0.0.1\n # rmmod tipc\n\n [] BUG: unable to handle kernel paging request at ffffffffc096bb00\n [] Workqueue: events 0xffffffffc096bb00\n [] Call Trace:\n [] ? process_one_work+0x1a7/0x360\n [] ? worker_thread+0x30/0x390\n [] ? create_worker+0x1a0/0x1a0\n [] ? kthread+0x116/0x130\n [] ? kthread_flush_work_fn+0x10/0x10\n [] ? ret_from_fork+0x35/0x40\n\nWhen removing the TIPC module, the UDP tunnel sock will be delayed to\nrelease in a work queue as sock_release() can\u0027t be done in rtnl_lock().\nIf the work queue is schedule to run after the TIPC module is removed,\nkernel will crash as the work queue function cleanup_beareri() code no\nlonger exists when trying to invoke it.\n\nTo fix it, this patch introduce a member wq_count in tipc_net to track\nthe numbers of work queues in schedule, and wait and exit until all\nwork queues are done in tipc_exit_net().",
"id": "GHSA-63cm-3458-95cr",
"modified": "2025-03-13T21:31:02Z",
"published": "2024-03-25T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04c26faa51d1e2fe71cf13c45791f5174c37f986"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5195ec5e365a2a9331bfeb585b613a6e94f98dba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9f5b7ad4ac3af006443f535b1ce7bff1d130d7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1f76dfadaf8f47ed1753f97dbcbd41c16215ffa"
}
],
"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-644J-VC34-VF98
Vulnerability from github – Published: 2026-04-13 15:31 – Updated: 2026-09-14 12:31In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.
{
"affected": [],
"aliases": [
"CVE-2026-31420"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-13T14:16:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes.",
"id": "GHSA-644j-vc34-vf98",
"modified": "2026-09-14T12:31:28Z",
"published": "2026-04-13T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31420"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ec86b4b9e28170a2565cf36f0e6e2b96b55134d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2120bd8546cd6a63c558d135773aa8f41c8259fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/610073ffb77ffd2b5eca182d2ac264de4834a175"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/630a15a31c2034b5b697f4aabc769b9d80d82446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9bc352f716d1bebfe43354bce539ec2d0223b30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8ec80430bfa520e7352155d6ac632e527cba7aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec8850be9b2b3beac1c7967d95f169dd2785979d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa6e24963342de4370e3a3c9af41e38277b74cf3"
}
],
"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.