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.
733 vulnerabilities reference this CWE, most recent first.
GHSA-73J2-7869-745F
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-17 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix locking order in ivpu_job_submit
Fix deadlock in job submission and abort handling. When a thread aborts currently executing jobs due to a fault, it first locks the global lock protecting submitted_jobs (#1).
After the last job is destroyed, it proceeds to release the related context and locks file_priv (#2). Meanwhile, in the job submission thread, the file_priv lock (#2) is taken first, and then the submitted_jobs lock (#1) is obtained when a job is added to the submitted jobs list.
CPU0 CPU1
---- ----
(for example due to a fault) (jobs submissions keep coming)
lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2
This order of locking causes a deadlock. To resolve this issue, change the order of locking in ivpu_job_submit().
{
"affected": [],
"aliases": [
"CVE-2025-37907"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix locking order in ivpu_job_submit\n\nFix deadlock in job submission and abort handling.\nWhen a thread aborts currently executing jobs due to a fault,\nit first locks the global lock protecting submitted_jobs (#1).\n\nAfter the last job is destroyed, it proceeds to release the related context\nand locks file_priv (#2). Meanwhile, in the job submission thread,\nthe file_priv lock (#2) is taken first, and then the submitted_jobs\nlock (#1) is obtained when a job is added to the submitted jobs list.\n\n CPU0 CPU1\n ---- \t ----\n (for example due to a fault) (jobs submissions keep coming)\n\n lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n ivpu_jobs_abort_all()\n job_destroy()\n lock(\u0026file_priv-\u003elock) #2\n lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n file_priv_release()\n lock(\u0026vdev-\u003econtext_list_lock)\n lock(\u0026file_priv-\u003elock) #2\n\nThis order of locking causes a deadlock. To resolve this issue,\nchange the order of locking in ivpu_job_submit().",
"id": "GHSA-73j2-7869-745f",
"modified": "2025-11-17T15:30:31Z",
"published": "2025-05-20T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37907"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab680dc6c78aa035e944ecc8c48a1caab9f39924"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b70924a272c2d72023306bc56f521c056212ee"
}
],
"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-752V-R57R-J98P
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-13 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/pci: Fix get_phb_number() locking
The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP warning on some systems:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64
This is because pcibios_alloc_controller() holds hose_spinlock but of_alias_get_id() takes of_mutex which can sleep.
The hose_spinlock protects the phb_bitmap, and also the hose_list, but it doesn't need to be held while get_phb_number() calls the OF routines, because those are only looking up information in the device tree.
So fix it by having get_phb_number() take the hose_spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs to take the lock again before the list_add() but that's safe, the order of the list is not important.
{
"affected": [],
"aliases": [
"CVE-2022-50045"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pci: Fix get_phb_number() locking\n\nThe recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP\nwarning on some systems:\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n 1 lock held by swapper/1:\n #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220\n Preemption disabled at:\n [\u003c00000000\u003e] 0x0\n CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1\n Call Trace:\n [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)\n [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8\n [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec\n [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4\n [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220\n [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784\n [d101de50] [c140852c] discover_phbs+0x30/0x4c\n [d101de60] [c0007fd4] do_one_initcall+0x94/0x344\n [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c\n [d101df10] [c00086e0] kernel_init+0x34/0x160\n [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64\n\nThis is because pcibios_alloc_controller() holds hose_spinlock but\nof_alias_get_id() takes of_mutex which can sleep.\n\nThe hose_spinlock protects the phb_bitmap, and also the hose_list, but\nit doesn\u0027t need to be held while get_phb_number() calls the OF routines,\nbecause those are only looking up information in the device tree.\n\nSo fix it by having get_phb_number() take the hose_spinlock itself, only\nwhere required, and then dropping the lock before returning.\npcibios_alloc_controller() then needs to take the lock again before the\nlist_add() but that\u0027s safe, the order of the list is not important.",
"id": "GHSA-752v-r57r-j98p",
"modified": "2025-11-13T21:31:18Z",
"published": "2025-06-18T12:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50045"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d9e75c3d8cdf7c96a94cb77450d4ee070279e6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5db5ce0f1963c6c8275719a80cb65e9c98d32726"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f75057c21eab12c6ccb7f06f859641a6edfab99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d48562a2729742f767b0fdd994d6b2a56a49c63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90f195c01a2e8d8da6281791617e21109719c981"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a868f771ee41c97a25a04b8c632a7f06689b307b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ccb0a42d3f40c436295e0fef57ab613ae5b925a4"
}
],
"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-75HW-9685-7HFF
Vulnerability from github – Published: 2023-12-08 21:30 – Updated: 2025-11-04 21:30Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412 where software, under certain circumstances, could deadlock a core due to the execution of either a load to device or non-cacheable memory, and either a store exclusive or register read of the Physical Address Register (PAR_EL1) in close proximity.
{
"affected": [],
"aliases": [
"CVE-2023-34320"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-08T21:15:07Z",
"severity": "MODERATE"
},
"details": "Cortex-A77 cores (r0p0 and r1p0) are affected by erratum 1508412\nwhere software, under certain circumstances, could deadlock a core\ndue to the execution of either a load to device or non-cacheable memory,\nand either a store exclusive or register read of the Physical\nAddress Register (PAR_EL1) in close proximity.",
"id": "GHSA-75hw-9685-7hff",
"modified": "2025-11-04T21:30:50Z",
"published": "2023-12-08T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34320"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-436.html"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-436.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-75WM-6772-RQF5
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31A lock screen issue allowed access to messages on a locked device. This issue was addressed with improved state management. This issue is fixed in iOS 14.0 and iPadOS 14.0. A person with physical access to an iOS device may be able to view notification contents from the lockscreen.
{
"affected": [],
"aliases": [
"CVE-2020-9959"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T17:15:00Z",
"severity": "LOW"
},
"details": "A lock screen issue allowed access to messages on a locked device. This issue was addressed with improved state management. This issue is fixed in iOS 14.0 and iPadOS 14.0. A person with physical access to an iOS device may be able to view notification contents from the lockscreen.",
"id": "GHSA-75wm-6772-rqf5",
"modified": "2022-05-24T17:31:11Z",
"published": "2022-05-24T17:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9959"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211850"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-762P-XX25-G6MQ
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
Revert "sched/fair: Make sure to try to detach at least one movable task"
This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.
b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu.
When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue.
{
"affected": [],
"aliases": [
"CVE-2024-42245"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T16:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"sched/fair: Make sure to try to detach at least one movable task\"\n\nThis reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.\n\nb0defa7ae03ec changed the load balancing logic to ignore env.max_loop if\nall tasks examined to that point were pinned. The goal of the patch was\nto make it more likely to be able to detach a task buried in a long list\nof pinned tasks. However, this has the unfortunate side effect of\ncreating an O(n) iteration in detach_tasks(), as we now must fully\niterate every task on a cpu if all or most are pinned. Since this load\nbalance code is done with rq lock held, and often in softirq context, it\nis very easy to trigger hard lockups. We observed such hard lockups with\na user who affined O(10k) threads to a single cpu.\n\nWhen I discussed this with Vincent he initially suggested that we keep\nthe limit on the number of tasks to detach, but increase the number of\ntasks we can search. However, after some back and forth on the mailing\nlist, he recommended we instead revert the original patch, as it seems\nlikely no one was actually getting hit by the original issue.",
"id": "GHSA-762p-xx25-g6mq",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-07T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42245"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d467194018dd536fe6c65a2fd3aedfcdb1424903"
},
{
"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-76F2-QJ4M-VMQR
Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2024-10-01 18:31In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting.
{
"affected": [],
"aliases": [
"CVE-2024-46868"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-27T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()\n\nIf the __qcuefi pointer is not set, then in the original code, we would\nhold onto the lock. That means that if we tried to set it later, then\nit would cause a deadlock. Drop the lock on the error path. That\u0027s\nwhat all the callers are expecting.",
"id": "GHSA-76f2-qj4m-vmqr",
"modified": "2024-10-01T18:31:17Z",
"published": "2024-09-27T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6a5a1fc02ad1d62d06897ab330693d4d27cd03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db213b0cfe3268d8b1d382b3bcc999c687a2567f"
}
],
"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-77MF-44MV-3M36
Vulnerability from github – Published: 2024-04-25 06:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.
{
"affected": [],
"aliases": [
"CVE-2024-26925"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-25T06:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: release mutex after nft_gc_seq_end from abort path\n\nThe commit mutex should not be released during the critical section\nbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC\nworker could collect expired objects and get the released commit lock\nwithin the same GC sequence.\n\nnf_tables_module_autoload() temporarily releases the mutex to load\nmodule dependencies, then it goes back to replay the transaction again.\nMove it at the end of the abort phase after nft_gc_seq_end() is called.",
"id": "GHSA-77mf-44mv-3m36",
"modified": "2026-05-12T12:31:41Z",
"published": "2024-04-25T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26925"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-354112.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/07/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/08/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-787P-86V4-HHFG
Vulnerability from github – Published: 2026-02-18 15:31 – Updated: 2026-03-18 18:31In the Linux kernel, the following vulnerability has been resolved:
riscv: trace: fix snapshot deadlock with sbi ecall
If sbi_ecall.c's functions are traceable,
echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter
may get the kernel into a deadlock.
(Functions in sbi_ecall.c are excluded from tracing if CONFIG_RISCV_ALTERNATIVE_EARLY is set.)
__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to __sbi_ecall and another snapshot...
All it takes to get into this endless loop is one initial __sbi_ecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger.
Always exclude the sbi_ecall.c functions from tracing to fix the potential deadlock.
sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation.
{
"affected": [],
"aliases": [
"CVE-2026-23217"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-18T15:18:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: trace: fix snapshot deadlock with sbi ecall\n\nIf sbi_ecall.c\u0027s functions are traceable,\n\necho \"__sbi_ecall:snapshot\" \u003e /sys/kernel/tracing/set_ftrace_filter\n\nmay get the kernel into a deadlock.\n\n(Functions in sbi_ecall.c are excluded from tracing if\nCONFIG_RISCV_ALTERNATIVE_EARLY is set.)\n\n__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code\nraises an IPI interrupt, which results in another call to __sbi_ecall\nand another snapshot...\n\nAll it takes to get into this endless loop is one initial __sbi_ecall.\nOn RISC-V systems without SSTC extension, the clock events in\ntimer-riscv.c issue periodic sbi ecalls, making the problem easy to\ntrigger.\n\nAlways exclude the sbi_ecall.c functions from tracing to fix the\npotential deadlock.\n\nsbi ecalls can easiliy be logged via trace events, excluding ecall\nfunctions from function tracing is not a big limitation.",
"id": "GHSA-787p-86v4-hhfg",
"modified": "2026-03-18T18:31:12Z",
"published": "2026-02-18T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23217"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0d7f5f0c9f05f1b6d4ee7110f15bef9c11f9df0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1f8285bc8e3508c1fde23b5205f1270215d4984"
}
],
"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-78H7-V2WQ-QPHC
Vulnerability from github – Published: 2022-05-17 00:35 – Updated: 2024-02-15 21:31The pfs_getextattr function in FreeBSD 7.x before 7.3-RELEASE and 8.x before 8.0-RC1 unlocks a mutex that was not previously locked, which allows local users to cause a denial of service (kernel panic), overwrite arbitrary memory locations, and possibly execute arbitrary code via vectors related to opening a file on a file system that uses pseudofs.
{
"affected": [],
"aliases": [
"CVE-2010-4210"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-11-22T12:54:00Z",
"severity": "HIGH"
},
"details": "The pfs_getextattr function in FreeBSD 7.x before 7.3-RELEASE and 8.x before 8.0-RC1 unlocks a mutex that was not previously locked, which allows local users to cause a denial of service (kernel panic), overwrite arbitrary memory locations, and possibly execute arbitrary code via vectors related to opening a file on a file system that uses pseudofs.",
"id": "GHSA-78h7-v2wq-qphc",
"modified": "2024-02-15T21:31:24Z",
"published": "2022-05-17T00:35:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4210"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/63218"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/15206"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42200"
},
{
"type": "WEB",
"url": "http://security.FreeBSD.org/advisories/FreeBSD-SA-10:09.pseudofs.asc"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1024724"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/2956"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-79HF-9RWH-4GV8
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2024-12-12 15:31In the Linux kernel, the following vulnerability has been resolved:
wifi: rt2x00: restart beacon queue when hardware reset
When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
{
"affected": [],
"aliases": [
"CVE-2023-52595"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rt2x00: restart beacon queue when hardware reset\n\nWhen a hardware reset is triggered, all registers are reset, so all\nqueues are forced to stop in hardware interface. However, mac80211\nwill not automatically stop the queue. If we don\u0027t manually stop the\nbeacon queue, the queue will be deadlocked and unable to start again.\nThis patch fixes the issue where Apple devices cannot connect to the\nAP after calling ieee80211_restart_hw().",
"id": "GHSA-79hf-9rwh-4gv8",
"modified": "2024-12-12T15:31:05Z",
"published": "2024-03-06T09:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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.