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.
731 vulnerabilities reference this CWE, most recent first.
GHSA-65R3-2H9P-MM4C
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
There is a deadlock in rtllib_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_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, rtllib_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-49315"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()\n\nThere is a deadlock in rtllib_beacons_stop(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | rtllib_send_beacon()\nrtllib_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | rtllib_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\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u003ebeacon_lock in position (2) of thread 2.\nAs a result, rtllib_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-65r3-2h9p-mm4c",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49315"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434"
}
],
"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-668P-X3M7-8W6V
Vulnerability from github – Published: 2024-01-17 18:31 – Updated: 2026-07-21 21:32A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2024-0639"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T16:15:46Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel\u2019s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.",
"id": "GHSA-668p-x3m7-8w6v",
"modified": "2026-07-21T21:32:03Z",
"published": "2024-01-17T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0639"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6583"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0639"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2258754"
}
],
"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-66MX-VW67-WMQ9
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-40981"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\n\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\n\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\n\n[1]\n\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last enabled at (6182793): [\u003cffff8000801dae10\u003e] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n process_scheduled_works kernel/workqueue.c:2706 [inline]\n worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n kthread+0x288/0x310 kernel/kthread.c:388\n ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---",
"id": "GHSA-66mx-vw67-wmq9",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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"
}
]
}
GHSA-674M-P5V7-MCQP
Vulnerability from github – Published: 2022-05-02 03:24 – Updated: 2024-02-15 21:31The ptrace_start function in kernel/ptrace.c in the Linux kernel 2.6.18 does not properly handle simultaneous execution of the do_coredump function, which allows local users to cause a denial of service (deadlock) via vectors involving the ptrace system call and a coredumping thread.
{
"affected": [],
"aliases": [
"CVE-2009-1388"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-07-05T16:30:00Z",
"severity": "MODERATE"
},
"details": "The ptrace_start function in kernel/ptrace.c in the Linux kernel 2.6.18 does not properly handle simultaneous execution of the do_coredump function, which allows local users to cause a denial of service (deadlock) via vectors involving the ptrace system call and a coredumping thread.",
"id": "GHSA-674m-p5v7-mcqp",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-02T03:24:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1388"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/attachment.cgi?id=346615"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/attachment.cgi?id=346742"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=504263"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8625"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8680"
},
{
"type": "WEB",
"url": "http://marc.info/?l=oss-security\u0026m=124654277229434\u0026w=2"
},
{
"type": "WEB",
"url": "http://osvdb.org/55679"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36131"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37471"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2009-1193.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/507985/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/35559"
},
{
"type": "WEB",
"url": "http://www.vmware.com/security/advisories/VMSA-2009-0016.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/3316"
}
],
"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-6767-7PJF-MXGF
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15A vulnerability in the Common Open Policy Service (COPS) of Cisco IOS XE Software for Cisco cBR-8 Converged Broadband Routers could allow an unauthenticated, remote attacker to cause resource exhaustion, resulting in a denial of service (DoS) condition. This vulnerability is due to a deadlock condition in the code when processing COPS packets under certain conditions. An attacker could exploit this vulnerability by sending COPS packets with high burst rates to an affected device. A successful exploit could allow the attacker to cause the CPU to consume excessive resources, which prevents other control plane processes from obtaining resources and results in a DoS.
{
"affected": [],
"aliases": [
"CVE-2021-1622"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-23T03:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Common Open Policy Service (COPS) of Cisco IOS XE Software for Cisco cBR-8 Converged Broadband Routers could allow an unauthenticated, remote attacker to cause resource exhaustion, resulting in a denial of service (DoS) condition. This vulnerability is due to a deadlock condition in the code when processing COPS packets under certain conditions. An attacker could exploit this vulnerability by sending COPS packets with high burst rates to an affected device. A successful exploit could allow the attacker to cause the CPU to consume excessive resources, which prevents other control plane processes from obtaining resources and results in a DoS.",
"id": "GHSA-6767-7pjf-mxgf",
"modified": "2022-05-24T19:15:39Z",
"published": "2022-05-24T19:15:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1622"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cbr8-cops-Vc2ZsJSx"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-67RW-G94P-PHV8
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-24 21:31In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix sleep in atomic at close time
Matt reported a splat at msk close time:
BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
4 locks held by packetdrill/155:
#0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)
#1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)
#2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)
#3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)
Preemption disabled at:
0x0
CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
__might_resched.cold (kernel/sched/core.c:9891)
__mptcp_destroy_sock (include/linux/kernel.h:110)
__mptcp_close (net/mptcp/protocol.c:2959)
mptcp_subflow_queue_clean (include/net/sock.h:1777)
__mptcp_close_ssk (net/mptcp/protocol.c:2363)
mptcp_destroy_common (net/mptcp/protocol.c:3170)
mptcp_destroy (include/net/sock.h:1495)
__mptcp_destroy_sock (net/mptcp/protocol.c:2886)
__mptcp_close (net/mptcp/protocol.c:2959)
mptcp_close (net/mptcp/protocol.c:2974)
inet_release (net/ipv4/af_inet.c:432)
__sock_release (net/socket.c:651)
sock_close (net/socket.c:1367)
__fput (fs/file_table.c:320)
task_work_run (kernel/task_work.c:181 (discriminator 1))
exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)
syscall_exit_to_user_mode (kernel/entry/common.c:130)
do_syscall_64 (arch/x86/entry/common.c:87)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
We can't call mptcp_close under the 'fast' socket lock variant, replace it with a sock_lock_nested() as the relevant code is already under the listening msk socket lock protection.
{
"affected": [],
"aliases": [
"CVE-2022-49018"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix sleep in atomic at close time\n\nMatt reported a splat at msk close time:\n\n BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill\n preempt_count: 201, expected: 0\n RCU nest depth: 0, expected: 0\n 4 locks held by packetdrill/155:\n #0: ffff888001536990 (\u0026sb-\u003es_type-\u003ei_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)\n #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)\n #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)\n #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)\n Preemption disabled at:\n 0x0\n CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n __might_resched.cold (kernel/sched/core.c:9891)\n __mptcp_destroy_sock (include/linux/kernel.h:110)\n __mptcp_close (net/mptcp/protocol.c:2959)\n mptcp_subflow_queue_clean (include/net/sock.h:1777)\n __mptcp_close_ssk (net/mptcp/protocol.c:2363)\n mptcp_destroy_common (net/mptcp/protocol.c:3170)\n mptcp_destroy (include/net/sock.h:1495)\n __mptcp_destroy_sock (net/mptcp/protocol.c:2886)\n __mptcp_close (net/mptcp/protocol.c:2959)\n mptcp_close (net/mptcp/protocol.c:2974)\n inet_release (net/ipv4/af_inet.c:432)\n __sock_release (net/socket.c:651)\n sock_close (net/socket.c:1367)\n __fput (fs/file_table.c:320)\n task_work_run (kernel/task_work.c:181 (discriminator 1))\n exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)\n syscall_exit_to_user_mode (kernel/entry/common.c:130)\n do_syscall_64 (arch/x86/entry/common.c:87)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\n\nWe can\u0027t call mptcp_close under the \u0027fast\u0027 socket lock variant, replace\nit with a sock_lock_nested() as the relevant code is already under the\nlistening msk socket lock protection.",
"id": "GHSA-67rw-g94p-phv8",
"modified": "2024-10-24T21:31:02Z",
"published": "2024-10-21T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49018"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4f166651d03b5484fa179817ba8ad4899a5a6ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8e6c5500dbf0f3e87aace90d4beba6ae928e866"
}
],
"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-683C-6FPF-JR2W
Vulnerability from github – Published: 2024-07-29 15:30 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Fix deadlock with the SPI chip variant
When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq:
watchdog: BUG: soft lockup - CPU#0 stuck for 27s!
call trace:
queued_spin_lock_slowpath+0x100/0x284
do_raw_spin_lock+0x34/0x44
ks8851_start_xmit_spi+0x30/0xb8
ks8851_start_xmit+0x14/0x20
netdev_start_xmit+0x40/0x6c
dev_hard_start_xmit+0x6c/0xbc
sch_direct_xmit+0xa4/0x22c
__qdisc_run+0x138/0x3fc
qdisc_run+0x24/0x3c
net_tx_action+0xf8/0x130
handle_softirqs+0x1ac/0x1f0
__do_softirq+0x14/0x20
____do_softirq+0x10/0x1c
call_on_irq_stack+0x3c/0x58
do_softirq_own_stack+0x1c/0x28
__irq_exit_rcu+0x54/0x9c
irq_exit_rcu+0x10/0x1c
el1_interrupt+0x38/0x50
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x64/0x68
__netif_schedule+0x6c/0x80
netif_tx_wake_queue+0x38/0x48
ks8851_irq+0xb8/0x2c8
irq_thread_fn+0x2c/0x74
irq_thread+0x10c/0x1b0
kthread+0xc8/0xd8
ret_from_fork+0x10/0x20
This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs.
Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-41036"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T15:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Fix deadlock with the SPI chip variant\n\nWhen SMP is enabled and spinlocks are actually functional then there is\na deadlock with the \u0027statelock\u0027 spinlock between ks8851_start_xmit_spi\nand ks8851_irq:\n\n watchdog: BUG: soft lockup - CPU#0 stuck for 27s!\n call trace:\n queued_spin_lock_slowpath+0x100/0x284\n do_raw_spin_lock+0x34/0x44\n ks8851_start_xmit_spi+0x30/0xb8\n ks8851_start_xmit+0x14/0x20\n netdev_start_xmit+0x40/0x6c\n dev_hard_start_xmit+0x6c/0xbc\n sch_direct_xmit+0xa4/0x22c\n __qdisc_run+0x138/0x3fc\n qdisc_run+0x24/0x3c\n net_tx_action+0xf8/0x130\n handle_softirqs+0x1ac/0x1f0\n __do_softirq+0x14/0x20\n ____do_softirq+0x10/0x1c\n call_on_irq_stack+0x3c/0x58\n do_softirq_own_stack+0x1c/0x28\n __irq_exit_rcu+0x54/0x9c\n irq_exit_rcu+0x10/0x1c\n el1_interrupt+0x38/0x50\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x64/0x68\n __netif_schedule+0x6c/0x80\n netif_tx_wake_queue+0x38/0x48\n ks8851_irq+0xb8/0x2c8\n irq_thread_fn+0x2c/0x74\n irq_thread+0x10c/0x1b0\n kthread+0xc8/0xd8\n ret_from_fork+0x10/0x20\n\nThis issue has not been identified earlier because tests were done on\na device with SMP disabled and so spinlocks were actually NOPs.\n\nNow use spin_(un)lock_bh for TX queue related locking to avoid execution\nof softirq work synchronously that would lead to a deadlock.",
"id": "GHSA-683c-6fpf-jr2w",
"modified": "2025-11-04T00:30:59Z",
"published": "2024-07-29T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41036"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80ece00137300d74642f2038c8fe5440deaf9f05"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0c69c492f4a8fad52f0a97565241c926160c9a4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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"
}
]
}
GHSA-684M-V6V9-3H53
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
r8169: fix LED-related deadlock on module removal
Binding devm_led_classdev_register() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions.
Note: We can safely call led_classdev_unregister() for a LED even if registering it failed, because led_classdev_unregister() detects this and is a no-op in this case.
{
"affected": [],
"aliases": [
"CVE-2024-27021"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: fix LED-related deadlock on module removal\n\nBinding devm_led_classdev_register() to the netdev is problematic\nbecause on module removal we get a RTNL-related deadlock. Fix this\nby avoiding the device-managed LED functions.\n\nNote: We can safely call led_classdev_unregister() for a LED even\nif registering it failed, because led_classdev_unregister() detects\nthis and is a no-op in this case.",
"id": "GHSA-684m-v6v9-3h53",
"modified": "2024-06-03T18:55:52Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27021"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19fa4f2a85d777a8052e869c1b892a2f7556569d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53d986f39acd8ea11c9e460732bfa5add66360d9"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-68J8-P6JF-3M4X
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") included a spin_lock() to change_page_attr() in order to safely perform the three step operations. But then commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against concurrent accesses") modify it to use pte_update() and do the operation safely against concurrent access.
In the meantime, Maxime reported some spinlock recursion.
[ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217 [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523 [ 15.373350] Workqueue: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c
Remove the read / modify / write sequence to make the operation atomic and remove the spin_lock() in change_page_attr().
To do the operation atomically, we can't use pte modification helpers anymore. Because all platforms have different combination of bits, it is not easy to use those bits directly. But all have the PAGE_KERNEL{RO/ROX/RW/RWX} set of flags. All we need it to compare two sets to know which bits are set or cleared.
For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you know which bit gets cleared and which bit get set when changing exec permission.
{
"affected": [],
"aliases": [
"CVE-2021-47632"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T06:37:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/set_memory: Avoid spinlock recursion in change_page_attr()\n\nCommit 1f9ad21c3b38 (\"powerpc/mm: Implement set_memory() routines\")\nincluded a spin_lock() to change_page_attr() in order to\nsafely perform the three step operations. But then\ncommit 9f7853d7609d (\"powerpc/mm: Fix set_memory_*() against\nconcurrent accesses\") modify it to use pte_update() and do\nthe operation safely against concurrent access.\n\nIn the meantime, Maxime reported some spinlock recursion.\n\n[ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217\n[ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0\n[ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523\n[ 15.373350] Workqueue: events do_free_init\n[ 15.377615] Call Trace:\n[ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable)\n[ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4\n[ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310\n[ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0\n[ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8\n[ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94\n[ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310\n[ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134\n[ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8\n[ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c\n[ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8\n[ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94\n[ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8\n[ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8\n[ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210\n[ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c\n\nRemove the read / modify / write sequence to make the operation atomic\nand remove the spin_lock() in change_page_attr().\n\nTo do the operation atomically, we can\u0027t use pte modification helpers\nanymore. Because all platforms have different combination of bits, it\nis not easy to use those bits directly. But all have the\n_PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare\ntwo sets to know which bits are set or cleared.\n\nFor instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you\nknow which bit gets cleared and which bit get set when changing exec\npermission.",
"id": "GHSA-68j8-p6jf-3m4x",
"modified": "2025-03-18T21:31:58Z",
"published": "2025-03-18T21:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47632"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6def4eaf0391f24be541633a954c0e4876858b1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ebe5ca2cbe438a688f2ae238ef5a0b0b5f3468a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96917107e67846f1d959ed03be281048efad14c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c182ecf33584b9b2d1aa9dad073014a504c01f"
}
],
"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-69HW-3R8X-9JF6
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-19 18:31In the Linux kernel, the following vulnerability has been resolved:
ftrace: Add cond_resched() to ftrace_graph_set_hash()
When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog.
Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions.
This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.
{
"affected": [],
"aliases": [
"CVE-2025-37940"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Add cond_resched() to ftrace_graph_set_hash()\n\nWhen the kernel contains a large number of functions that can be traced,\nthe loop in ftrace_graph_set_hash() may take a lot of time to execute.\nThis may trigger the softlockup watchdog.\n\nAdd cond_resched() within the loop to allow the kernel to remain\nresponsive even when processing a large number of functions.\n\nThis matches the cond_resched() that is used in other locations of the\ncode that iterates over all functions that can be traced.",
"id": "GHSA-69hw-3r8x-9jf6",
"modified": "2025-12-19T18:31:05Z",
"published": "2025-05-20T18:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37940"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42ea22e754ba4f2b86f8760ca27f6f71da2d982c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4429535acab750d963fdc3dfcc9e0eee42f4d599"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d336ac215e5c76e43ef4bca9ba699835e53e2fd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/618655d54c5f8af5d57b77491d08c0f0ff77d114"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72be43ff061a889c6ee648a330a42486cafa15a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dd7d7280357596ba63dfdb4c1725d9dd24bd42a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd38803c9088b848c6b56f4f6d7efc4497bfde61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5b4ae6f01d4a510d5725eca7254519a1093920d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.