Bug 801648 - (CVE-2012-1148) CVE-2012-1148 expat: Memory leak in poolGrow
CVE-2012-1148 expat: Memory leak in poolGrow
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 811830 811831 811832 811833 811834 811835 811836 811837 982563 982566 1200324 1200326 1238182 1351488
Blocks: 801654 1286624 1395463
  Show dependency treegraph
Reported: 2012-03-08 23:54 EST by Kurt Seifried
Modified: 2018-03-05 10:28 EST (History)
62 users (show)

See Also:
Fixed In Version: expat 2.1.0
Doc Type: Bug Fix
Doc Text:
A memory leak flaw was found in Expat. If an XML file processed by an application linked against Expat triggered a memory re-allocation failure, Expat failed to free the previously allocated memory. This could cause the application to exit unexpectedly or crash when all available memory is exhausted.
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2012-03-08 23:54:47 EST
Tim Boddy reported a memory leak in poolGrow [1]

This bug applies at least to 1.95.8, 2.0.0 and 2.0.1

poolGrow in xml.parse.cpp has the following block of code:
  if (pool->blocks && pool->start == pool->blocks->s) {
    int blockSize = (int)(pool->end - pool->start)*2;
    pool->blocks = (BLOCK *)
                             (offsetof(BLOCK, s)
                              + blockSize * sizeof(XML_Char)));
    if (pool->blocks == NULL)
      return XML_FALSE;
    pool->blocks->size = blockSize;
    pool->ptr = pool->blocks->s + (pool->ptr - pool->start);
    pool->start = pool->blocks->s;
    pool->end = pool->start + blockSize;
It looks like this will cause a memory leak if realloc_fcn returns NULL because pool->blocks will be overwritten but the old memory area to which it pointed won't be freed.
The other places where reallocation is done in this file (via the REALLOC macro) don't have this bug because they correctly store the result in a temporary variable.
This bug allows a serious DOS attack on a server that accepts XML-based requests if a request is seen of the following form:

<!DOCTYPE foo [
<!ENTITY a "1234567890" >
<!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;" >
<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;" >
<!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;" >
<!ENTITY e "&d;&d;&d;&d;&d;&d;&d;&d;" >
<!ENTITY f "&e;&e;&e;&e;&e;&e;&e;&e;" >
<!ENTITY g "&f;&f;&f;&f;&f;&f;&f;&f;" >
<!ENTITY h "&g;&g;&g;&g;&g;&g;&g;&g;" >
<!ENTITY i "&h;&h;&h;&h;&h;&h;&h;&h;" >
<!ENTITY j "&i;&i;&i;&i;&i;&i;&i;&i;" >
<!ENTITY k "&j;&j;&j;&j;&j;&j;&j;&j;" >
<!ENTITY l "&k;&k;&k;&k;&k;&k;&k;&k;" >
<!ENTITY m "&l;&l;&l;&l;&l;&l;&l;&l;" >
<!ENTITY n "&m;&m;&m;&m;&m;&m;&m;&m;" >
<foo bar="&n;"/>

When the attribute is expanded, the realloc (assuming that it bounds the size of the request) will fail, leaking the buffer from before the realloc.

Comment 7 errata-xmlrpc 2012-06-13 10:01:15 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5

Via RHSA-2012:0731 https://rhn.redhat.com/errata/RHSA-2012-0731.html
Comment 8 Jan Lieskovsky 2013-07-09 06:08:22 EDT
Created compat-expat1 tracking bugs for this issue:

Affects: fedora-all [bug 982563]
Comment 16 errata-xmlrpc 2016-01-21 10:55:30 EST
This issue has been addressed in the following products:

  JBoss Web Server 2.1.0

Via RHSA-2016:0062 https://rhn.redhat.com/errata/RHSA-2016-0062.html
Comment 17 errata-xmlrpc 2016-12-15 17:13:03 EST
This issue has been addressed in the following products:

Via RHSA-2016:2957 https://rhn.redhat.com/errata/RHSA-2016-2957.html

Note You need to log in before you can comment on or make changes to this bug.