via rh bugzilla


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 = XML_ERROR_NO_MEMORY;
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 = XML_ERROR_NO_MEMORY;
return NULL;
else {
do {
bufferSize *= 2;
} while (bufferSize < neededSize);
}

Both cases leads to not eliminating the vulnerability.

Upstream patch:

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


References:
https://bugzilla.redhat.com/show_bug.cgi?id=1344251
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4472