A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.

Accessibility. A privacy issue was addressed by removing sensitive data.

libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.

In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.

libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.

In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.

In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.

libexpat before 2.8.2 has an integer overflow in storeAtts.

libexpat before 2.8.2 has an integer overflow in copyString.

xmlwf in libexpat before 2.8.2 has an integer overflow in resolveSystemId.

libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.

libexpat before 2.8.2 has an integer overflow in getAttributeId.

libexpat before 2.8.2 has an integer overflow in XMLParseBuffer because it lacked a check that was present in XMLParse.

libexpat before 2.8.2 has an integer overflow in addBinding.

xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.

xmlwf in libexpat before 2.8.2 has an integer overflow for the output filename when -d outputDir is used.

xml.parsers.expat and xml.etree.ElementTree use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.

libexpat before 2.8.2 lacks handler call depth tracking for calls to XMLGetBuffer, XMLParse, XMLParseBuffer, XMLParserFree, or XMLParserReset from within handlers in cases of a policy violation. Thus, a use-after-free can occur,

libexpat before 2.8.2 does not consider XMLTOKDATACHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.

libexpat before 2.8.2 lacks handler call depth tracking for calls to XMLResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).

An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XMLParseBuffer.

An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINTMAX equals SIZEMAX).

An issue was discovered in libexpat before 2.6.4. There is a crash within the XMLResumeParser function because XMLStopParser can stop/suspend an unstarted parser.

The libexpat library is vulnerable to a stack overflow due to uncontrolled recursion when processing deeply nested XML entities. This can cause the application to crash, resulting in a denial of service (DoS) or potentially leading to memory corruption, depending on the user's environment and how the library is used. The issue is triggered by supplying a specially crafted XML document designed to create a long chain of recursive entities.

When an Expat parser with a registered ElementDeclHandler parses an inline document type definition containing a deeply nested content model a C stack overflow occurs.

The Expat XML parser mishandles certain kinds of malformed input documents, resulting in buffer overflows during processing and error reporting. The overflows can manifest as a segmentation fault or as memory corruption during a parse operation. The bugs allow for a denial of service attack in many applications by an unauthenticated attacker, and could conceivably result in remote code execution.

It was found that original patch for issues CVE-2015-1283 and CVE-2015-2716 used overflow checks that could be optimized out by some compilers applying certain optimization settings, which can cause the vulnerability to remain even after applying the patch.

One pattern in the fix for CVE-2015-1283/CVE-2015-2716 is:

/ bufferSize is positive here / do { bufferSize = 2; } while (bufferSize < neededSize && bufferSize > 0); if (bufferSize <= 0) { errorCode = XMLERRORNOMEMORY; return NULL;

Any of the modern optimizing compiler, IF able to infer that bufferSize is initially positive (which is true but not obvious to see through local reasoning), will eliminate bufferSize > 0 as always true when the execution is defined, and bufferSize <= 0 as always false when the execution is defined.

Without knowing that bufferSize starts positive, an optimizing compiler could also move the test bufferSize > 0 out of the loop, that is, compile the code as if it had been written:

if (bufferSize <= 0) errorCode = XMLERRORNOMEMORY; return NULL; else { do { bufferSize = 2; } while (bufferSize < neededSize); }

Both cases leads to not eliminating the vulnerability.

Upstream patch:

https://sourceforge.net/p/expat/codegit/ci/f0bec73b018caa07d3e75ec8dd967f3785d71bde/tree/expat/lib/xmlparse.c?diff=a238d7ea7a715ef3850c4cbdd86aeda7077b6bbc

On 3/15/24 09:57, Alan Coopersmith wrote: https://blog.hartwork.org/posts/expat-2-6-2-released/ (published 2024-03-13) announces the release of Expat 2.6.2, with security fixes: [...] The blog also points to the call for help maintaining libexpat in the Changelog at https://github.com/libexpat/libexpat/blob/R262/expat/Changes which notes that items that need someone to work on include:

!! - <blink>fixing a complex non-public security issue</blink>,              !! Expat 2.7.0 has now been released with a fix for that issue, and the issue has been disclosed in: https://blog.hartwork.org/posts/expat-2-7-0-released/ https://github.com/libexpat/libexpat/issues/893 https://github.com/libexpat/libexpat/pull/973

Jann Horn of Google Project Zero is credited with reporting the issue, while Siemens is credited with making the fix, and Red Hat, Linutronix, and a company that would not like to be named, are credited for helping test the fix.

The short summary from the bug report:

A long linear chain of entity references: long enough to force the recursion in Expat into stack overflow.

How long the chain needs to be depends on the stack size of the target machine. To illustrate the structure:

# python3 payload1.py 2 <!DOCTYPE doc [ <!ENTITY e0 ''> <!ENTITY e1 '&e0;'> <!ENTITY e2 '&e1;'> ]> <doc>&e2;</doc>

# python3 payload2.py 2 <!DOCTYPE a [ <!ENTITY e0 ''> <!ENTITY e1 '&e0;'> <!ENTITY e2 '&e1;'> ]> <a key='&e2;'/>

# python3 payload3.py 2 <!DOCTYPE doc [ <!ENTITY % p0 ''> <!ENTITY % p1 '&#37;p0;'> <!ENTITY % p2 '&#37;p1;'> <!ENTITY % defineg0 "<!ENTITY g0 '&#37;p2;'>"> %defineg0; ]> <doc/>

(The payload.py scripts are linked from https://github.com/libexpat/libexpat/issues/893)

The blog requests that "you please tell your friends:

Please leave recursion to math and keep it out of (in particular C) software: it kills and will kill again. Kind regards from libexpat, see CVE-2022-25313 and CVE-2024-8176 for proof."

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hello,

A vulnerability (CVE-2024-8176) has been fixed in expat, a widely used xml parser library: https://blog.hartwork.org/posts/expat-2-7-0-released/ Info about the vuln has been posted here already. expat 2.7.0 fixes multiple variations of stack overflows due to recursion and can be triggered by using a large number of nested entities. Scripts to generate example payloads for testing can be found in the project's issue tracker: https://github.com/libexpat/libexpat/issues/893

I had some discussions with the maintainer of expat before this was published about the security impact. We believe that this is likely, in most cases, "only" a crash/denial of service type of bug.

Here is what I believe to be the case:

Recursion stack overflow can lead to a stack clash, which might enable memory corruption and code execution. There has been some detailed investigation of this type of vulnerability by Qualys in 2017: https://blog.qualys.com/vulnerabilities-threat-research/2017/06/19/the-stack-clash https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

As a response to this research, it was concluded that existing countermeasures for these types of vulnerabilities are insufficient, and a new compiler flag -fstack-clash-protection was introduced: https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3 The -fstack-clash-protection flag is available in recent versions of gcc and clang, and many distributions have it enabled by default. There also have been changes to glibc and the Linux kernel in response: https://bugzilla.redhat.com/showbug.cgi?id=CVE-2017-1000366 (glibc) https://bugzilla.redhat.com/showbug.cgi?id=CVE-2017-1000364 (Linux kernel)

I believe from the above that current systems should not be vulnerable to this type of vulnerability. I am unsure about systems that do not apply -fstack-clash-protection. My understanding of these types of vulnerabilities is limited, and by posting this here, I hope that people more familiar with it will have a closer look. I am also not sure how widely these mitigations have been applied and whether there are major distributions not using -fstack-clash-protection by default.

-- Hanno Böck - Independent security researcher https://itsec.hboeck.de/ https://badkeys.info/