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.
616 vulnerabilities reference this CWE, most recent first.
GHSA-5528-5VMV-3XC2
Vulnerability from github – Published: 2026-03-05 00:27 – Updated: 2026-03-05 00:27Impact
A vulnerability in Multer versions < 2.1.1 allows an attacker to trigger a Denial of Service (DoS) by sending malformed requests, potentially causing stack overflow.
Patches
Users should upgrade to 2.1.1
Workarounds
None
Resources
- https://github.com/expressjs/multer/security/advisories/GHSA-5528-5vmv-3xc2
- https://www.cve.org/CVERecord?id=CVE-2026-3520
- https://github.com/expressjs/multer/commit/7e66481f8b2e6c54b982b34c152479e096ce2752
- https://cna.openjsf.org/security-advisories.html
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "multer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-3520"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T00:27:50Z",
"nvd_published_at": "2026-03-04T17:16:22Z",
"severity": "HIGH"
},
"details": "### Impact\n\nA vulnerability in Multer versions \u003c 2.1.1 allows an attacker to trigger a Denial of Service (DoS) by sending malformed requests, potentially causing stack overflow.\n\n### Patches\n\nUsers should upgrade to `2.1.1`\n\n### Workarounds\n\nNone\n\n### Resources\n\n- https://github.com/expressjs/multer/security/advisories/GHSA-5528-5vmv-3xc2\n- https://www.cve.org/CVERecord?id=CVE-2026-3520\n- https://github.com/expressjs/multer/commit/7e66481f8b2e6c54b982b34c152479e096ce2752\n- https://cna.openjsf.org/security-advisories.html",
"id": "GHSA-5528-5vmv-3xc2",
"modified": "2026-03-05T00:27:50Z",
"published": "2026-03-05T00:27:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/security/advisories/GHSA-5528-5vmv-3xc2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3520"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/commit/7e66481f8b2e6c54b982b34c152479e096ce2752"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/expressjs/multer"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3520"
}
],
"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": "Multer Vulnerable to Denial of Service via Uncontrolled Recursion"
}
GHSA-554W-WPV2-VW27
Vulnerability from github – Published: 2025-11-26 22:08 – Updated: 2025-11-26 22:08Summary
An Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs.
Details
An ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge asn1.fromDer function within forge/lib/asn1.js. The ASN.1 DER parser implementation (_fromDer) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw RangeError: Maximum call stack size exceeded, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects.
Impact
This vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing.
This vulnerability impacts the ans1.fromDer function in node-forge before patched version 1.3.2.
Any downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "node-forge"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66031"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-26T22:08:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nAn Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs.\n\n### Details\n\nAn ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge `asn1.fromDer` function within `forge/lib/asn1.js`. The ASN.1 DER parser implementation (`_fromDer`) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw `RangeError: Maximum call stack size exceeded`, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects.\n\n### Impact\n\nThis vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing.\n\nThis vulnerability impacts the ans1.fromDer function in `node-forge` before patched version `1.3.2`. \n\nAny downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability.",
"id": "GHSA-554w-wpv2-vw27",
"modified": "2025-11-26T22:08:37Z",
"published": "2025-11-26T22:08:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/digitalbazaar/forge/security/advisories/GHSA-554w-wpv2-vw27"
},
{
"type": "WEB",
"url": "https://github.com/digitalbazaar/forge/commit/260425c6167a38aae038697132483b5517b26451"
},
{
"type": "PACKAGE",
"url": "https://github.com/digitalbazaar/forge"
}
],
"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": "node-forge has ASN.1 Unbounded Recursion"
}
GHSA-55FH-FMPQ-W8H6
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-05-27 15:32In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Fix recursive locking in __configfs_open_file()
In flush_write_buffer, &p->frag_sem is acquired and then the loaded store function is called, which, here, is target_core_item_dbroot_store(). This function called filp_open(), following which these functions were called (in reverse order), according to the call trace:
down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter
target_core_item_dbroot_store() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows:
db_root: not a directory: /sys/kernel/config/target/dbroot
indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire frag_sem semaphore of the same file of which it already holds the semaphore obtained in flush_write_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking.
Fix this by modifying target_core_item_dbroot_store() to use kern_path() instead of filp_open() to avoid opening the file using filesystem-specific function __configfs_open_file(), and further modifying it to make this fix compatible.
{
"affected": [],
"aliases": [
"CVE-2026-23292"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix recursive locking in __configfs_open_file()\n\nIn flush_write_buffer, \u0026p-\u003efrag_sem is acquired and then the loaded store\nfunction is called, which, here, is target_core_item_dbroot_store(). This\nfunction called filp_open(), following which these functions were called\n(in reverse order), according to the call trace:\n\n down_read\n __configfs_open_file\n do_dentry_open\n vfs_open\n do_open\n path_openat\n do_filp_open\n file_open_name\n filp_open\n target_core_item_dbroot_store\n flush_write_buffer\n configfs_write_iter\n\ntarget_core_item_dbroot_store() tries to validate the new file path by\ntrying to open the file path provided to it; however, in this case, the bug\nreport shows:\n\ndb_root: not a directory: /sys/kernel/config/target/dbroot\n\nindicating that the same configfs file was tried to be opened, on which it\nis currently working on. Thus, it is trying to acquire frag_sem semaphore\nof the same file of which it already holds the semaphore obtained in\nflush_write_buffer(), leading to acquiring the semaphore in a nested manner\nand a possibility of recursive locking.\n\nFix this by modifying target_core_item_dbroot_store() to use kern_path()\ninstead of filp_open() to avoid opening the file using filesystem-specific\nfunction __configfs_open_file(), and further modifying it to make this fix\ncompatible.",
"id": "GHSA-55fh-fmpq-w8h6",
"modified": "2026-05-27T15:32:59Z",
"published": "2026-03-25T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23292"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/142eacb50fb903a4c10dee7e67b6e79ebb36a582"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14d4ac19d1895397532eec407433c5d74d9da53b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3161ef61f121d4573cad5b57c92188dcd9b284b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4fcfa424a581d823cb1a9676e3eefe6ca17e453a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a5641024fbfd9b24fe65984ad85fea10a3ae438"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8ef82cb6443d5f3260b1b830e17f03dda4229ea"
}
],
"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-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"
}
]
}
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.