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.
713 vulnerabilities reference this CWE, most recent first.
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-06-01 18: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-06-01T18:31:23Z",
"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/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/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"
}
]
}
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"
}
]
}
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.