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-2XMX-R7CC-9X6C
Vulnerability from github – Published: 2025-07-28 12:30 – Updated: 2025-11-19 18:31In the Linux kernel, the following vulnerability has been resolved:
tracing/osnoise: Fix crash in timerlat_dump_stack()
We have observed kernel panics when using timerlat with stack saving, with the following dmesg output:
memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
__timerlat_dump_stack() constructs the ftrace stack entry like this:
struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries;
Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow.
Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack().
{
"affected": [],
"aliases": [
"CVE-2025-38493"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T12:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Fix crash in timerlat_dump_stack()\n\nWe have observed kernel panics when using timerlat with stack saving,\nwith the following dmesg output:\n\nmemcpy: detected buffer overflow: 88 byte write of buffer size 0\nWARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0\nCPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy)\nCall Trace:\n \u003cTASK\u003e\n ? trace_buffer_lock_reserve+0x2a/0x60\n __fortify_panic+0xd/0xf\n __timerlat_dump_stack.cold+0xd/0xd\n timerlat_dump_stack.part.0+0x47/0x80\n timerlat_fd_read+0x36d/0x390\n vfs_read+0xe2/0x390\n ? syscall_exit_to_user_mode+0x1d5/0x210\n ksys_read+0x73/0xe0\n do_syscall_64+0x7b/0x160\n ? exc_page_fault+0x7e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n__timerlat_dump_stack() constructs the ftrace stack entry like this:\n\nstruct stack_entry *entry;\n...\nmemcpy(\u0026entry-\u003ecaller, fstack-\u003ecalls, size);\nentry-\u003esize = fstack-\u003enr_entries;\n\nSince commit e7186af7fb26 (\"tracing: Add back FORTIFY_SOURCE logic to\nkernel_stack event structure\"), struct stack_entry marks its caller\nfield with __counted_by(size). At the time of the memcpy, entry-\u003esize\ncontains garbage from the ringbuffer, which under some circumstances is\nzero, triggering a kernel panic by buffer overflow.\n\nPopulate the size field before the memcpy so that the out-of-bounds\ncheck knows the correct size. This is analogous to\n__ftrace_trace_stack().",
"id": "GHSA-2xmx-r7cc-9x6c",
"modified": "2025-11-19T18:31:17Z",
"published": "2025-07-28T12:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38493"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bb9ea515cda027c9e717e27fefcf34f092e7c41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/823d798900481875ba6c68217af028c5ffd2976b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85a3bce695b361d85fc528e6fbb33e4c8089c806"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fbf90f5aa7ac7cddc69148a71d58f12c8709ce2b"
}
],
"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-2XWF-CG9M-5547
Vulnerability from github – Published: 2022-05-14 02:12 – Updated: 2022-05-14 02:12The xmlStringGetNodeList function in tree.c in libxml2 2.9.3 and earlier, when used in recovery mode, allows context-dependent attackers to cause a denial of service (infinite recursion, stack consumption, and application crash) via a crafted XML document.
{
"affected": [],
"aliases": [
"CVE-2016-3627"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-05-17T14:08:00Z",
"severity": "HIGH"
},
"details": "The xmlStringGetNodeList function in tree.c in libxml2 2.9.3 and earlier, when used in recovery mode, allows context-dependent attackers to cause a denial of service (infinite recursion, stack consumption, and application crash) via a crafted XML document.",
"id": "GHSA-2xwf-cg9m-5547",
"modified": "2022-05-14T02:12:12Z",
"published": "2022-05-14T02:12:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3627"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1292"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05157239"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10170"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201701-37"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2016/dsa-3593"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/tns-2016-18"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-05/msg00055.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-05/msg00127.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2957.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2016/May/10"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/03/21/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/03/21/3"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/bulletinjul2016-3090568.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinjul2016-3090544.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/ovmbulletinjul2016-3090546.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/84992"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1035335"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2994-1"
}
],
"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"
}
]
}
GHSA-327R-8GQ8-599M
Vulnerability from github – Published: 2023-07-06 21:14 – Updated: 2024-04-04 05:42In Xpdf 4.04 (and earlier), a PDF object loop in the embedded file tree leads to infinite recursion and a stack overflow.
{
"affected": [],
"aliases": [
"CVE-2023-2664"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-11T21:15:10Z",
"severity": "MODERATE"
},
"details": "\u00a0In Xpdf 4.04 (and earlier), a PDF object loop in the embedded file tree leads to infinite recursion and a stack overflow.\n\n\n",
"id": "GHSA-327r-8gq8-599m",
"modified": "2024-04-04T05:42:37Z",
"published": "2023-07-06T21:14:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2664"
},
{
"type": "WEB",
"url": "https://forum.xpdfreader.com/viewtopic.php?t=42422"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-32GM-G888-8WVJ
Vulnerability from github – Published: 2022-05-24 21:59 – Updated: 2023-02-01 21:30When FreeImage 3.18.0 reads a special TIFF file, the TIFFReadDirectory function in PluginTIFF.cpp always returns 1, leading to stack exhaustion.
{
"affected": [],
"aliases": [
"CVE-2019-12213"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-20T16:29:00Z",
"severity": "MODERATE"
},
"details": "When FreeImage 3.18.0 reads a special TIFF file, the TIFFReadDirectory function in PluginTIFF.cpp always returns 1, leading to stack exhaustion.",
"id": "GHSA-32gm-g888-8wvj",
"modified": "2023-02-01T21:30:23Z",
"published": "2022-05-24T21:59:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12213"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/12/msg00012.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PUWVVP67FYM4GMWD7TPQ7C7JPPRUZHYE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VZ7KBYPPNRMX7RRWVJSX4T63E3TFB6TG"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Dec/45"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-02"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4529-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4593"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-337M-MW94-2V6G
Vulnerability from github – Published: 2026-05-14 12:30 – Updated: 2026-05-20 15:36Uncontrolled Recursion vulnerability in Apache Commons.
When processing an untrusted configuration file, Commons Configuration will throw a StackOverflowError for YAML input with cycles. This issue affects Apache Commons: from 2.2 before 2.15.0.
Users are recommended to upgrade to version 2.15.0, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.commons:commons-configuration2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2"
},
{
"fixed": "2.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45205"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-20T15:36:43Z",
"nvd_published_at": "2026-05-14T12:16:35Z",
"severity": "MODERATE"
},
"details": "Uncontrolled Recursion vulnerability in Apache Commons.\n\nWhen processing an untrusted configuration file, Commons Configuration will throw a StackOverflowError for YAML input with cycles.\nThis issue affects Apache Commons: from 2.2 before 2.15.0.\n\nUsers are recommended to upgrade to version 2.15.0, which fixes the issue.",
"id": "GHSA-337m-mw94-2v6g",
"modified": "2026-05-20T15:36:43Z",
"published": "2026-05-14T12:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45205"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-configuration/pull/634"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-configuration"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/q3q3j10ohcqhs6o0rg1v7kz6kk27vtkk"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/14/5"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Apache Commons Configuration: StackOverflowError for YAML input with cycles"
}
GHSA-3393-HVRJ-W7V3
Vulnerability from github – Published: 2021-08-09 20:41 – Updated: 2021-08-02 19:21In Elasticsearch versions before 7.13.3 and 6.8.17 an uncontrolled recursion vulnerability that could lead to a denial of service attack was identified in the Elasticsearch Grok parser. A user with the ability to submit arbitrary queries to Elasticsearch could create a malicious Grok query that will crash the Elasticsearch node.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.elasticsearch:elasticsearch"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.8.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.elasticsearch:elasticsearch"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-alpha1"
},
{
"fixed": "7.13.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-22144"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-02T19:21:25Z",
"nvd_published_at": "2021-07-26T12:15:00Z",
"severity": "MODERATE"
},
"details": "In Elasticsearch versions before 7.13.3 and 6.8.17 an uncontrolled recursion vulnerability that could lead to a denial of service attack was identified in the Elasticsearch Grok parser. A user with the ability to submit arbitrary queries to Elasticsearch could create a malicious Grok query that will crash the Elasticsearch node.",
"id": "GHSA-3393-hvrj-w7v3",
"modified": "2021-08-02T19:21:25Z",
"published": "2021-08-09T20:41:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22144"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-7-13-3-and-6-8-17-security-update/278100"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210827-0006"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of Service in Elasticsearch"
}
GHSA-354H-3W43-8PJM
Vulnerability from github – Published: 2025-09-18 18:30 – Updated: 2025-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
powercap: arm_scmi: Remove recursion while parsing zones
Powercap zones can be defined as arranged in a hierarchy of trees and when registering a zone with powercap_register_zone(), the kernel powercap subsystem expects this to happen starting from the root zones down to the leaves; on the other side, de-registration by powercap_deregister_zone() must begin from the leaf zones.
Available SCMI powercap zones are retrieved dynamically from the platform at probe time and, while any defined hierarchy between the zones is described properly in the zones descriptor, the platform returns the availables zones with no particular well-defined order: as a consequence, the trees possibly composing the hierarchy of zones have to be somehow walked properly to register the retrieved zones from the root.
Currently the ARM SCMI Powercap driver walks the zones using a recursive algorithm; this approach, even though correct and tested can lead to kernel stack overflow when processing a returned hierarchy of zones composed by particularly high trees.
Avoid possible kernel stack overflow by substituting the recursive approach with an iterative one supported by a dynamically allocated stack-like data structure.
{
"affected": [],
"aliases": [
"CVE-2023-53428"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T16:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowercap: arm_scmi: Remove recursion while parsing zones\n\nPowercap zones can be defined as arranged in a hierarchy of trees and when\nregistering a zone with powercap_register_zone(), the kernel powercap\nsubsystem expects this to happen starting from the root zones down to the\nleaves; on the other side, de-registration by powercap_deregister_zone()\nmust begin from the leaf zones.\n\nAvailable SCMI powercap zones are retrieved dynamically from the platform\nat probe time and, while any defined hierarchy between the zones is\ndescribed properly in the zones descriptor, the platform returns the\navailables zones with no particular well-defined order: as a consequence,\nthe trees possibly composing the hierarchy of zones have to be somehow\nwalked properly to register the retrieved zones from the root.\n\nCurrently the ARM SCMI Powercap driver walks the zones using a recursive\nalgorithm; this approach, even though correct and tested can lead to kernel\nstack overflow when processing a returned hierarchy of zones composed by\nparticularly high trees.\n\nAvoid possible kernel stack overflow by substituting the recursive approach\nwith an iterative one supported by a dynamically allocated stack-like data\nstructure.",
"id": "GHSA-354h-3w43-8pjm",
"modified": "2025-12-11T18:30:34Z",
"published": "2025-09-18T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53428"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e767d6850f867cc33ac16ca097350a1d2417982"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8022b64fb7daa6135d9f7b0e2f7b5b8e9e5179c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b427c23cebc5c926516f20304bf1acc05a33d147"
}
],
"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-364H-VXJM-52RP
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-22 15:31A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).
{
"affected": [],
"aliases": [
"CVE-2026-6862"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:17:08Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node\u0027s Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).",
"id": "GHSA-364h-vxjm-52rp",
"modified": "2026-04-22T15:31:45Z",
"published": "2026-04-22T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6862"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-6862"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2459982"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-369H-PJR2-6WRH
Vulnerability from github – Published: 2021-08-25 20:43 – Updated: 2023-06-13 22:25There's a stack overflow leading to a crash when Trust-DNS's parses a malicious DNS packet. Affected versions of this crate did not properly handle parsing of DNS message compression (RFC1035 section 4.1.4). The parser could be tricked into infinite loop when a compression offset pointed back to the same domain name to be parsed. This allows an attacker to craft a malicious DNS packet which when consumed with Trust-DNS could cause stack overflow and crash the affected software.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "trust-dns-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-20994"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T21:24:41Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "There\u0027s a stack overflow leading to a crash when Trust-DNS\u0027s parses a malicious DNS packet. Affected versions of this crate did not properly handle parsing of DNS message compression (RFC1035 section 4.1.4). The parser could be tricked into infinite loop when a compression offset pointed back to the same domain name to be parsed. This allows an attacker to craft a malicious DNS packet which when consumed with Trust-DNS could cause stack overflow and crash the affected software.",
"id": "GHSA-369h-pjr2-6wrh",
"modified": "2023-06-13T22:25:06Z",
"published": "2021-08-25T20:43:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20994"
},
{
"type": "PACKAGE",
"url": "https://github.com/bluejekyll/trust-dns"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2018-0007.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 trust-dns-proto"
}
GHSA-382J-8MXH-C7X2
Vulnerability from github – Published: 2026-06-25 18:35 – Updated: 2026-06-25 18:35Summary
MessagePackReader.ReadDateTime() can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed tokenSize includes the extension body length from the wire and is used in a stackalloc operation before the extension length is validated as one of the valid timestamp sizes.
A very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable StackOverflowException, terminating the host process.
Impact
Applications are affected when they deserialize untrusted payloads into types containing DateTime values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.
MessagePackSecurity.UntrustedData and MaximumObjectGraphDepth do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.
An attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.
Affected components
- Package:
MessagePack - API:
MessagePackReader.ReadDateTime - Data types:
DateTimeand formatter paths that callReadDateTime - Finding IDs:
MESSAGEPACKCSHARP-020, related stack allocation findingMESSAGEPACKCSHARP-CROW-MEM-001
Patches
Fixes are prepared and will be released in coordinated patch versions.
Upgrade guidance:
- Upgrade
MessagePackto the patched version for your release line. - Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.
The fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.
Workarounds
Patching is recommended.
Until a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain DateTime or DateTimeOffset values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.
There is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.
Resources
MESSAGEPACKCSHARP-020:ReadDateTimestack allocation from attacker-controlled extension lengthMESSAGEPACKCSHARP-CROW-MEM-001: related attacker-controlled stack allocation finding inMessagePackReader- CWE-770: Allocation of Resources Without Limits or Throttling
CVE split rationale
This vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "MessagePack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48502"
],
"database_specific": {
"cwe_ids": [
"CWE-1188",
"CWE-125",
"CWE-190",
"CWE-407",
"CWE-409",
"CWE-470",
"CWE-502",
"CWE-674",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:35:48Z",
"nvd_published_at": "2026-06-22T22:16:47Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`MessagePackReader.ReadDateTime()` can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed `tokenSize` includes the extension body length from the wire and is used in a `stackalloc` operation before the extension length is validated as one of the valid timestamp sizes.\n\nA very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable `StackOverflowException`, terminating the host process.\n\n## Impact\n\nApplications are affected when they deserialize untrusted payloads into types containing `DateTime` values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.\n\n`MessagePackSecurity.UntrustedData` and `MaximumObjectGraphDepth` do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.\n\nAn attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.\n\n## Affected components\n\n- Package: `MessagePack`\n- API: `MessagePackReader.ReadDateTime`\n- Data types: `DateTime` and formatter paths that call `ReadDateTime`\n- Finding IDs: `MESSAGEPACKCSHARP-020`, related stack allocation finding `MESSAGEPACKCSHARP-CROW-MEM-001`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain `DateTime` or `DateTimeOffset` values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.\n\nThere is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-020`: `ReadDateTime` stack allocation from attacker-controlled extension length\n- `MESSAGEPACKCSHARP-CROW-MEM-001`: related attacker-controlled stack allocation finding in `MessagePackReader`\n- CWE-770: Allocation of Resources Without Limits or Throttling\n\n## CVE split rationale\n\nThis vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.",
"id": "GHSA-382j-8mxh-c7x2",
"modified": "2026-06-25T18:35:48Z",
"published": "2026-06-25T18:35:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-382j-8mxh-c7x2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48502"
},
{
"type": "PACKAGE",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows"
}
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.