Total
364 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-57257 | 1 Denx | 1 U-boot | 2025-11-03 | 2 Low |
| A stack consumption issue in sqfs_size in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with deep symlink nesting. | ||||
| CVE-2025-9714 | 2 Gnome, Xmlsoft | 2 Libxml2, Libxml2 | 2025-11-03 | 6.2 Medium |
| Uncontrolled recursion in XPath evaluation in libxml2 up to and including version 2.9.14 allows a local attacker to cause a stack overflow via crafted expressions. XPath processing functions `xmlXPathRunEval`, `xmlXPathCtxtCompile`, and `xmlXPathEvalExpr` were resetting recursion depth to zero before making potentially recursive calls. When such functions were called recursively this could allow for uncontrolled recursion and lead to a stack overflow. These functions now preserve recursion depth across recursive calls, allowing recursion depth to be controlled. | ||||
| CVE-2023-52986 | 1 Linux | 1 Linux Kernel | 2025-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener A listening socket linked to a sockmap has its sk_prot overridden. It points to one of the struct proto variants in tcp_bpf_prots. The variant depends on the socket's family and which sockmap programs are attached. A child socket cloned from a TCP listener initially inherits their sk_prot. But before cloning is finished, we restore the child's proto to the listener's original non-tcp_bpf_prots one. This happens in tcp_create_openreq_child -> tcp_bpf_clone. Today, in tcp_bpf_clone we detect if the child's proto should be restored by checking only for the TCP_BPF_BASE proto variant. This is not correct. The sk_prot of listening socket linked to a sockmap can point to to any variant in tcp_bpf_prots. If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then the child socket unintentionally is left if the inherited sk_prot by tcp_bpf_clone. This leads to issues like infinite recursion on close [1], because the child state is otherwise not set up for use with tcp_bpf_prot operations. Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants. Note that it wouldn't be sufficient to check the socket state when overriding the sk_prot in tcp_bpf_update_proto in order to always use the TCP_BPF_BASE variant for listening sockets. Since commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") it is possible for a socket to transition to TCP_LISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ | ||||
| CVE-2022-23460 | 1 Hjiang | 1 Json\+\+ | 2025-10-28 | 5.9 Medium |
| Jsonxx or Json++ is a JSON parser, writer and reader written in C++. In affected versions of jsonxx json parsing may lead to stack exhaustion in an address sanitized (ASAN) build. This issue may lead to Denial of Service if the program using the jsonxx library crashes. This issue exists on the current commit of the jsonxx project and the project itself has been archived. Updates are not expected. Users are advised to find a replacement. | ||||
| CVE-2025-54858 | 1 F5 | 3 Big-ip, Big-ip Advanced Web Application Firewall, Big-ip Application Security Manager | 2025-10-21 | 7.5 High |
| When a BIG-IP Advanced WAF or BIG-IP ASM Security Policy is configured with a JSON content profile that has a malformed JSON schema, and the security policy is applied to a virtual server, undisclosed requests can cause the bd process to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
| CVE-2025-11896 | 1 Xpdf | 1 Xpdf | 2025-10-21 | N/A |
| In Xpdf 4.05 (and earlier), a PDF object loop in a CMap, via the "UseCMap" entry, leads to infinite recursion and a stack overflow. | ||||
| CVE-2022-30631 | 2 Golang, Redhat | 21 Go, Acm, Advanced Cluster Security and 18 more | 2025-10-20 | 7.5 High |
| Uncontrolled recursion in Reader.Read in compress/gzip before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via an archive containing a large number of concatenated 0-length compressed files. | ||||
| CVE-2025-33096 | 3 Ibm, Linux, Microsoft | 4 Aix, Engineering Requirements Management Doors Next, Linux Kernel and 1 more | 2025-10-16 | 6.5 Medium |
| IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 could allow an authenticated user to cause a denial of service by uploading specially crafted files using uncontrolled recursion. | ||||
| CVE-2025-1752 | 1 Llamaindex | 1 Llamaindex | 2025-10-15 | 5.3 Medium |
| A Denial of Service (DoS) vulnerability has been identified in the KnowledgeBaseWebReader class of the run-llama/llama_index project, affecting version ~ latest(v0.12.15). The vulnerability arises due to inappropriate secure coding measures, specifically the lack of proper implementation of the max_depth parameter in the get_article_urls function. This allows an attacker to exhaust Python's recursion limit through repeated function calls, leading to resource consumption and ultimately crashing the Python process. | ||||
| CVE-2024-12910 | 1 Llamaindex | 1 Llamaindex | 2025-10-15 | 5.9 Medium |
| A vulnerability in the `KnowledgeBaseWebReader` class of the run-llama/llama_index repository, version latest, allows an attacker to cause a Denial of Service (DoS) by controlling a URL variable to contain the root URL. This leads to infinite recursive calls to the `get_article_urls` method, exhausting system resources and potentially crashing the application. | ||||
| CVE-2024-2965 | 1 Langchain | 1 Langchain | 2025-10-15 | 4.7 Medium |
| A Denial-of-Service (DoS) vulnerability exists in the `SitemapLoader` class of the `langchain-ai/langchain` repository, affecting all versions. The `parse_sitemap` method, responsible for parsing sitemaps and extracting URLs, lacks a mechanism to prevent infinite recursion when a sitemap URL refers to the current sitemap itself. This oversight allows for the possibility of an infinite loop, leading to a crash by exceeding the maximum recursion depth in Python. This vulnerability can be exploited to occupy server socket/port resources and crash the Python process, impacting the availability of services relying on this functionality. | ||||
| CVE-2024-58102 | 1 Datalust | 1 Seq | 2025-10-10 | 5.7 Medium |
| An issue was discovered in Datalust Seq before 2024.3.13545. An insecure default parsing depth limit allows stack consumption when parsing user-supplied queries containing deeply nested expressions. | ||||
| CVE-2025-50420 | 1 Freedesktop | 1 Poppler | 2025-10-09 | 6.5 Medium |
| An issue in the pdfseparate utility of freedesktop poppler v25.04.0 allows attackers to cause an infinite recursion via supplying a crafted PDF file. This can lead to a Denial of Service (DoS). | ||||
| CVE-2025-61766 | 1 Mediawiki | 1 Mediawiki | 2025-10-08 | 6.5 Medium |
| Bucket is a MediaWiki extension to store and retrieve structured data on articles. Prior to version 1.0.0, infinite recursion can occur if a user queries a bucket using the `!=` comparator. This will result in PHP's call stack limit exceeding, and/or increased memory consumption, potentially leading to a denial of service. Version 1.0.0 contains a patch for the issue. | ||||
| CVE-2025-43718 | 1 Poppler | 1 Poppler | 2025-10-06 | 2.9 Low |
| Poppler 24.06.1 through 25.x before 25.04.0 allows stack consumption and a SIGSEGV via deeply nested structures within the metadata (such as GTS_PDFEVersion) of a PDF document, e.g., a regular expression for a long pdfsubver string. This occurs in Dict::lookup, Catalog::getMetadata, and associated functions in PDFDoc, with deep recursion in the regex executor (std::__detail::_Executor). | ||||
| CVE-2025-10728 | 1 Qt | 1 Qt | 2025-10-06 | 4.0 Medium |
| When the module renders a Svg file that contains a <pattern> element, it might end up rendering it recursively leading to stack overflow DoS | ||||
| CVE-2025-46206 | 1 Artifex | 1 Mupdf | 2025-10-02 | 6.5 Medium |
| An issue in Artifex mupdf 1.25.6, 1.25.5 allows a remote attacker to cause a denial of service via an infinite recursion in the `mutool clean` utility. When processing a crafted PDF file containing cyclic /Next references in the outline structure, the `strip_outline()` function enters infinite recursion | ||||
| CVE-2024-7254 | 3 Google, Netapp, Redhat | 15 Google-protobuf, Protobuf, Protobuf-java and 12 more | 2025-09-26 | 7.5 High |
| Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. | ||||
| CVE-2021-47465 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stores CR/LR into its callers frame (per the ABI). The problem is that there is no caller frame on the emergency stack. The emergency stack for a given CPU is allocated with: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; So emergency_sp actually points to the first address above the emergency stack allocation for a given CPU, we must not store above it without first decrementing it to create a frame. This is different to the regular kernel stack, paca->kstack, which is initialised to point at an initial frame that is ready to use. idle_kvm_start_guest() stores the backchain, CR and LR all of which write outside the allocation for the emergency stack. It then creates a stack frame and saves the non-volatile registers. Unfortunately the frame it creates is not large enough to fit the non-volatiles, and so the saving of the non-volatile registers also writes outside the emergency stack allocation. The end result is that we corrupt whatever is at 0-24 bytes, and 112-248 bytes above the emergency stack allocation. In practice this has gone unnoticed because the memory immediately above the emergency stack happens to be used for other stack allocations, either another CPUs mc_emergency_sp or an IRQ stack. See the order of calls to irqstack_early_init() and emergency_stack_init(). The low addresses of another stack are the top of that stack, and so are only used if that stack is under extreme pressue, which essentially never happens in practice - and if it did there's a high likelyhood we'd crash due to that stack overflowing. Still, we shouldn't be corrupting someone else's stack, and it is purely luck that we aren't corrupting something else. To fix it we save CR/LR into the caller's frame using the existing r1 on entry, we then create a SWITCH_FRAME_SIZE frame (which has space for pt_regs) on the emergency stack with the backchain pointing to the existing stack, and then finally we switch to the new frame on the emergency stack. | ||||
| CVE-2025-43708 | 1 Visicut | 1 Visicut | 2025-09-24 | 3.3 Low |
| VisiCut 2.1 allows stack consumption via an XML document with nested set elements, as demonstrated by a java.util.HashMap StackOverflowError when reference='../../../set/set[2]' is used, aka an "insecure deserialization" issue. | ||||