CWE-674
Allowed-with-ReviewUncontrolled Recursion
Abstraction: Class · Status: Draft
The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.
751 vulnerabilities reference this CWE, most recent first.
GHSA-56PQ-53X9-MXC4
Vulnerability from github – Published: 2026-07-20 12:33 – Updated: 2026-07-20 12:33SurrealDB before 3.1.0 fails to enforce recursion depth limits in the type/kind parser when processing nested type annotations. Authenticated attackers can send queries with deeply nested type annotations to exhaust server memory and crash the process.
{
"affected": [],
"aliases": [
"CVE-2026-63759"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T12:19:46Z",
"severity": "HIGH"
},
"details": "SurrealDB before 3.1.0 fails to enforce recursion depth limits in the type/kind parser when processing nested type annotations. Authenticated attackers can send queries with deeply nested type annotations to exhaust server memory and crash the process.",
"id": "GHSA-56pq-53x9-mxc4",
"modified": "2026-07-20T12:33:11Z",
"published": "2026-07-20T12:33:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-q8qp-67f9-wr3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63759"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/surrealdb-before-denial-of-service-nested-type-annotations"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-58FJ-7XRF-2V4Q
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-18 18:32In the Linux kernel, the following vulnerability has been resolved:
powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable
commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown.
During some of the perf runs, below warning is hit:
WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in:
NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220
This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet:
<<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>>
Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk:
<<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>>
Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")
Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC.
2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-50118"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable\n\ncommit 2c9ac51b850d (\"powerpc/perf: Fix PMU callbacks to clear\npending PMI before resetting an overflown PMC\") added a new\nfunction \"pmi_irq_pending\" in hw_irq.h. This function is to check\nif there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is\nused in power_pmu_disable in a WARN_ON. The intention here is to\nprovide a warning if there is PMI pending, but no counter is found\noverflown.\n\nDuring some of the perf runs, below warning is hit:\n\nWARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0\n Modules linked in:\n -----\n\n NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0\n LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0\n Call Trace:\n [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)\n [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60\n [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100\n [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240\n [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140\n [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0\n [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300\n [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100\n [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40\n [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250\n [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0\n [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0\n [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80\n [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0\n [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140\n [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8\n [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0\n [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220\n\nThis means that there is no PMC overflown among the active events\nin the PMU, but there is a PMU pending in Paca. The function\n\"any_pmc_overflown\" checks the PMCs on active events in\ncpuhw-\u003en_events. Code snippet:\n\n\u003c\u003c\u003e\u003e\nif (any_pmc_overflown(cpuhw))\n \tclear_pmi_irq_pending();\n else\n \tWARN_ON(pmi_irq_pending());\n\u003c\u003c\u003e\u003e\n\nHere the PMC overflown is not from active event. Example: When we do\nperf record, default cycles and instructions will be running on PMC6\nand PMC5 respectively. It could happen that overflowed event is currently\nnot active and pending PMI is for the inactive event. Debug logs from\ntrace_printk:\n\n\u003c\u003c\u003e\u003e\nany_pmc_overflown: idx is 5: pmc value is 0xd9a\npower_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011\n\u003c\u003c\u003e\u003e\n\nHere active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).\nWhen we handle PMI interrupt for such cases, if the PMC overflown is\nfrom inactive event, it will be ignored. Reference commit:\ncommit bc09c219b2e6 (\"powerpc/perf: Fix finding overflowed PMC in interrupt\")\n\nPatch addresses two changes:\n1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )\n We were printing warning if no PMC is found overflown among active PMU\n events, but PMI pending in PACA. But this could happen in cases where\n PMC overflown is not in active PMC. An inactive event could have caused\n the overflow. Hence the warning is not needed. To know pending PMI is\n from an inactive event, we need to loop through all PMC\u0027s which will\n cause more SPR reads via mfspr and increase in context switch. Also in\n existing function: perf_event_interrupt, already we ignore PMI\u0027s\n overflown when it is from an inactive PMC.\n\n2) Fix 2: optimization in clearing pending PMI.\n Currently we check for any active PMC overflown before clearing PMI\n pending in Paca. This is causing additional SP\n---truncated---",
"id": "GHSA-58fj-7xrf-2v4q",
"modified": "2025-11-18T18:32:45Z",
"published": "2025-06-18T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50118"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce"
}
],
"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-59QW-42JC-WW5F
Vulnerability from github – Published: 2023-01-21 21:30 – Updated: 2025-04-03 15:30A remote attacker might be able to cause infinite recursion in PowerDNS Recursor 4.8.0 via a DNS query that retrieves DS records for a misconfigured domain, because QName minimization is used in QM fallback mode. This is fixed in 4.8.1.
{
"affected": [],
"aliases": [
"CVE-2023-22617"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-21T19:15:00Z",
"severity": "HIGH"
},
"details": "A remote attacker might be able to cause infinite recursion in PowerDNS Recursor 4.8.0 via a DNS query that retrieves DS records for a misconfigured domain, because QName minimization is used in QM fallback mode. This is fixed in 4.8.1.",
"id": "GHSA-59qw-42jc-ww5f",
"modified": "2025-04-03T15:30:48Z",
"published": "2023-01-21T21:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22617"
},
{
"type": "WEB",
"url": "https://docs.powerdns.com/recursor/changelog/4.8.html#change-4.8.1"
},
{
"type": "WEB",
"url": "https://docs.powerdns.com/recursor/security-advisories"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/01/20/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5CMR-4PX5-23PC
Vulnerability from github – Published: 2025-08-25 20:43 – Updated: 2025-09-10 21:06Summary
This issue: http://github.com/mlc-ai/xgrammar/issues/250 should have it's own security advisory. Since several tools accept and pass user supplied grammars to xgrammar, and it is so easy to trigger it seems like a High.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "xgrammar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-57809"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-25T20:43:45Z",
"nvd_published_at": "2025-08-25T22:15:33Z",
"severity": "HIGH"
},
"details": "### Summary\nThis issue: http://github.com/mlc-ai/xgrammar/issues/250 should have it\u0027s own security advisory. Since several tools accept and pass user supplied grammars to xgrammar, and it is so easy to trigger it seems like a High.",
"id": "GHSA-5cmr-4px5-23pc",
"modified": "2025-09-10T21:06:51Z",
"published": "2025-08-25T20:43:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-5cmr-4px5-23pc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57809"
},
{
"type": "WEB",
"url": "https://github.com/mlc-ai/xgrammar/issues/250"
},
{
"type": "WEB",
"url": "https://github.com/mlc-ai/xgrammar/commit/b943feacb5a1caf4d39de8ec3bf7c7ce066dcee5"
},
{
"type": "PACKAGE",
"url": "https://github.com/mlc-ai/xgrammar"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "XGrammar affected by Denial of Service by infinite recursion grammars"
}
GHSA-5F94-F58J-VGQV
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling
The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") restructured the EEH driver to improve synchronization with the PCI hotplug layer.
However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths.
This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking.
Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition.
Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention.
The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus bus) which retrieves the location code for given bus.
This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario:
[ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK ***
[ 84.964388] [ T928] May be due to missing lock nesting notation
[ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-45904"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling\n\nThe recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device\nhotplug safe\") restructured the EEH driver to improve synchronization\nwith the PCI hotplug layer.\n\nHowever, it inadvertently moved pci_lock_rescan_remove() outside its\nintended scope in eeh_handle_normal_event(), leading to broken PCI\nerror reporting and improper EEH event triggering. Specifically,\neeh_handle_normal_event() acquired pci_lock_rescan_remove() before\ncalling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to\nacquire the same lock internally, causing nested locking and disrupting\nnormal EEH event handling paths.\n\nThis patch adds a boolean parameter do_lock to _eeh_pe_bus_get(),\nwith two public wrappers:\n eeh_pe_bus_get() with locking enabled.\n eeh_pe_bus_get_nolock() that skips locking.\n\nCallers that already hold pci_lock_rescan_remove() now use\neeh_pe_bus_get_nolock() to avoid recursive lock acquisition.\n\nAdditionally, pci_lock_rescan_remove() calls are restored to the correct\nposition\u2014after eeh_pe_bus_get() and immediately before iterating affected\nPEs and devices. This ensures EEH-triggered PCI removes occur under proper\nbus rescan locking without recursive lock contention.\n\nThe eeh_pe_loc_get() function has been split into two functions:\n eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE.\n eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location\n code for given bus.\n\nThis resolves lockdep warnings such as:\n\u003csnip\u003e\n[ 84.964298] [ T928] ============================================\n[ 84.964304] [ T928] WARNING: possible recursive locking detected\n[ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted\n[ 84.964315] [ T928] --------------------------------------------\n[ 84.964320] [ T928] eehd/928 is trying to acquire lock:\n[ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40\n[ 84.964342] [ T928]\n but task is already holding lock:\n[ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40\n[ 84.964357] [ T928]\n other info that might help us debug this:\n[ 84.964363] [ T928] Possible unsafe locking scenario:\n\n[ 84.964367] [ T928] CPU0\n[ 84.964370] [ T928] ----\n[ 84.964373] [ T928] lock(pci_rescan_remove_lock);\n[ 84.964378] [ T928] lock(pci_rescan_remove_lock);\n[ 84.964383] [ T928]\n *** DEADLOCK ***\n\n[ 84.964388] [ T928] May be due to missing lock nesting notation\n\n[ 84.964393] [ T928] 1 lock held by eehd/928:\n[ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40\n[ 84.964408] [ T928]\n stack backtrace:\n[ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY\n[ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries\n[ 84.964419] [ T928] Call Trace:\n[ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable)\n[ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440\n[ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80\n[ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410\n[ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050\n[ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40\n[ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0\n[ 84.964442] [ T928] [c0000011a7157e50] [c00000\n---truncated---",
"id": "GHSA-5f94-f58j-vgqv",
"modified": "2026-06-24T18:32:27Z",
"published": "2026-05-27T15:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45904"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e6561231c6cfc32c5631aeecc0928ff2b14265c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/788dd28fd49610d6047cbb15dbf1186afffdfbaf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/815a8d2feb5615ae7f0b5befd206af0b0160614c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87a1f93986aa1500b85aeff16b0b71c29ea116ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89810e2d80281d42f855fac813786758ee16e323"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b85ee287bfe52c6b2d9b41758b5e0d08679d5b39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f49faa4a64f8ac0e38983e606075b25dfcfc9ad4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8b16d5764ee1e78c1ef333017ad383ffe76fcdc"
}
],
"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-5FH8-WC7H-JJMX
Vulnerability from github – Published: 2022-05-13 01:52 – Updated: 2022-05-13 01:52In Exiv2 0.26, there is a segmentation fault caused by uncontrolled recursion in the Exiv2::Image::printIFDStructure function in the image.cpp file. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted tif file.
{
"affected": [],
"aliases": [
"CVE-2018-5772"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-18T07:29:00Z",
"severity": "MODERATE"
},
"details": "In Exiv2 0.26, there is a segmentation fault caused by uncontrolled recursion in the Exiv2::Image::printIFDStructure function in the image.cpp file. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted tif file.",
"id": "GHSA-5fh8-wc7h-jjmx",
"modified": "2022-05-13T01:52:55Z",
"published": "2022-05-13T01:52:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5772"
},
{
"type": "WEB",
"url": "https://github.com/Exiv2/exiv2/issues/216"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201811-14"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102789"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5FHX-39R8-3JWH
Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2026-03-06 18:31Uncontrolled recursion in Decoder.Decode in encoding/gob before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via a message which contains deeply nested structures.
{
"affected": [],
"aliases": [
"CVE-2022-30635"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-10T20:15:00Z",
"severity": "HIGH"
},
"details": "Uncontrolled recursion in Decoder.Decode in encoding/gob before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via a message which contains deeply nested structures.",
"id": "GHSA-5fhx-39r8-3jwh",
"modified": "2026-03-06T18:31:10Z",
"published": "2022-08-11T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30635"
},
{
"type": "WEB",
"url": "https://go.dev/cl/417064"
},
{
"type": "WEB",
"url": "https://go.dev/issue/53615"
},
{
"type": "WEB",
"url": "https://go.googlesource.com/go/+/6fa37e98ea4382bf881428ee0c150ce591500eb7"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/nqrv9fbR0zE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RQXU752ALW53OJAF5MG3WMR5CCZVLWW6"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0526"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5FRV-4H27-CPHV
Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-05-13 01:18EOSIO/eos eos version after commit f1545dd0ae2b77580c2236fdb70ae7138d2c7168 contains a stack overflow vulnerability in abi_serializer that can result in attack eos network node. This attack appear to be exploitable via network request. This vulnerability appears to have been fixed in after commit cf7209e703e6d3f7a5413e0cb1fe88a4d8e4b38d .
{
"affected": [],
"aliases": [
"CVE-2018-1000618"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-09T20:29:00Z",
"severity": "CRITICAL"
},
"details": "EOSIO/eos eos version after commit f1545dd0ae2b77580c2236fdb70ae7138d2c7168 contains a stack overflow vulnerability in abi_serializer that can result in attack eos network node. This attack appear to be exploitable via network request. This vulnerability appears to have been fixed in after commit cf7209e703e6d3f7a5413e0cb1fe88a4d8e4b38d .",
"id": "GHSA-5frv-4h27-cphv",
"modified": "2022-05-13T01:18:47Z",
"published": "2022-05-13T01:18:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000618"
},
{
"type": "WEB",
"url": "https://github.com/EOSIO/eos/pull/4112"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5HP8-35WJ-M525
Vulnerability from github – Published: 2021-08-25 20:44 – Updated: 2021-08-19 21:23An issue was discovered in the ammonia crate before 2.1.0 for Rust. There is uncontrolled recursion during HTML DOM tree serialization.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ammonia"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-15542"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T21:23:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "An issue was discovered in the ammonia crate before 2.1.0 for Rust. There is uncontrolled recursion during HTML DOM tree serialization.",
"id": "GHSA-5hp8-35wj-m525",
"modified": "2021-08-19T21:23:38Z",
"published": "2021-08-25T20:44:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15542"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-ammonia/ammonia"
},
{
"type": "WEB",
"url": "https://github.com/rust-ammonia/ammonia/blob/master/CHANGELOG.md#210"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2019-0001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncontrolled recursion in ammonia"
}
GHSA-5JG4-P4QW-CGFR
Vulnerability from github – Published: 2026-04-04 05:33 – Updated: 2026-04-07 14:22Summary
@stablelib/cbor decodes nested CBOR structures recursively and does not enforce a maximum nesting depth. A sufficiently deep attacker-controlled CBOR payload can therefore crash decoding with RangeError: Maximum call stack size exceeded.
Details
The decoder processes arrays, maps, and tagged values through recursive calls. Each nested container causes another descent into _decodeValue() until a leaf value is reached.
There is no depth limit, no iterative fallback, and no protection against pathological nesting. An attacker can therefore supply a payload made of thousands of nested arrays, maps, or tags and force the decoder to recurse until the JavaScript call stack is exhausted.
PoC
import { decode } from "@stablelib/cbor";
const depth = 12000;
const payload = new Uint8Array(depth + 1);
// Build [[[...[null]...]]]
payload.fill(0x81, 0, depth); // array(1)
payload[depth] = 0xf6; // null
decode(payload);
// RangeError: Maximum call stack size exceeded
Impact
Any application that decodes attacker-controlled CBOR can be forced into a reliable denial of service with a single crafted payload.
The immediate result is an exception during decoding. In services that do not catch that exception safely, the request fails and the worker or process handling the decode may terminate.
Solution
Upgrade to version 2.0.4. The stack is limited to 128 by default, but can be configured using the maxDepth option. Catch the CBORMaxDepthExceededError exception.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@stablelib/cbor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T05:33:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`@stablelib/cbor` decodes nested CBOR structures recursively and does not enforce a maximum nesting depth. A sufficiently deep attacker-controlled CBOR payload can therefore crash decoding with `RangeError: Maximum call stack size exceeded`.\n\n### Details\n\nThe decoder processes arrays, maps, and tagged values through recursive calls. Each nested container causes another descent into `_decodeValue()` until a leaf value is reached.\n\nThere is no depth limit, no iterative fallback, and no protection against pathological nesting. An attacker can therefore supply a payload made of thousands of nested arrays, maps, or tags and force the decoder to recurse until the JavaScript call stack is exhausted.\n\n### PoC\n\n```js\nimport { decode } from \"@stablelib/cbor\";\n\nconst depth = 12000;\nconst payload = new Uint8Array(depth + 1);\n\n// Build [[[...[null]...]]]\npayload.fill(0x81, 0, depth); // array(1)\npayload[depth] = 0xf6; // null\n\ndecode(payload);\n// RangeError: Maximum call stack size exceeded\n```\n\n### Impact\n\nAny application that decodes attacker-controlled CBOR can be forced into a reliable denial of service with a single crafted payload.\n\nThe immediate result is an exception during decoding. In services that do not catch that exception safely, the request fails and the worker or process handling the decode may terminate.\n\n\n### Solution\n\nUpgrade to version 2.0.4. The stack is limited to 128 by default, but can be configured using the `maxDepth` option. Catch the `CBORMaxDepthExceededError` exception.",
"id": "GHSA-5jg4-p4qw-cgfr",
"modified": "2026-04-07T14:22:35Z",
"published": "2026-04-04T05:33:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/StableLib/stablelib/security/advisories/GHSA-5jg4-p4qw-cgfr"
},
{
"type": "WEB",
"url": "https://github.com/StableLib/stablelib/commit/0149e18d9d4736e22c257744ca945ebce7899a01"
},
{
"type": "PACKAGE",
"url": "https://github.com/StableLib/stablelib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@stablelib/cbor: Stack exhaustion Denial of Service via deeply nested CBOR arrays, maps, or tags"
}
Mitigation
Ensure that an end condition will be reached under all logic conditions. The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.
Mitigation
Increase the stack size.
CAPEC-230: Serialized Data with Nested Payloads
Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.
CAPEC-231: Oversized Serialized Data Payloads
An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.