configure.in | 2 1 + 1 - 0 !
libxml-2.0-uninstalled.pc.in | 3 2 + 1 - 0 !
libxml-2.0.pc.in | 2 1 + 1 - 0 !
xml2-config.1 | 4 4 + 0 - 0 !
xml2-config.in | 22 10 + 12 - 0 !
5 files changed, 18 insertions(+), 15 deletions(-)

 modify xml2-config and pkgconfig behaviour

python/Makefile.am | 2 1 + 1 - 0 !
python/Makefile.in | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 fix python multiarch includes

parser.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix an error in xmlcleanupparser

https://bugzilla.gnome.org/show_bug.cgi?id=698582

xmlCleanupParser calls xmlCleanupGlobals() and then
xmlResetLastError() but the later reallocate the global
data freed by previous call. Just swap the two calls.

python/libxml.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 fix missing break on last() function for attributes

pointed out by cppcheck

xmllint.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

 xmllint --memory should fail on empty files

Exposed by https://bugzilla.gnome.org/show_bug.cgi?id=699896
when doing analysis but a priori unrelated.

c14n.c | 9 5 + 4 - 0 !
1 file changed, 5 insertions(+), 4 deletions(-)

 properly quote the namespace uris written out during c14n

parser.c | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 fix a parsing bug on non-ascii element and cr/lf usage

https://bugzilla.gnome.org/show_bug.cgi?id=698550

Somehow the behaviour of the internal parser routine changed
slightly when encountering CR/LF, which led to a bug when
parsing document with non-ascii Names

xlink.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 missing else in xlink.c

Obviously forgotten

xmllint.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 catch malloc error and exit accordingly

As pointed privately by Bill Parker <wp02855@gmail.com>

xmllint.c | 13 11 + 2 - 0 !
1 file changed, 11 insertions(+), 2 deletions(-)

 fix handling of mmap errors

https://bugzilla.gnome.org/show_bug.cgi?id=702320

as raised by Gaurav <ya1gaurav@gmail.com>

xmlschemastypes.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 avoid crash if allocation fails

https://bugzilla.gnome.org/show_bug.cgi?id=704527
xmlSchemaNewValue() may fail on OOM error

SAX2.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 fix a possible null dereference

https://bugzilla.gnome.org/show_bug.cgi?id=705400
In case of allocation error the pointer was dereferenced before the
test for a failure

parserInternals.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 clear up a potential null dereference

https://bugzilla.gnome.org/show_bug.cgi?id=705399

if ctxt->node_seq.buffer is null then ctxt->node_seq.maximum ought
to be zero but it's better to clarify the check in the code directly.

xpath.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 fix xpath '//' optimization with predicates

My attempt to optimize XPath expressions containing '//' caused a
regression reported in bug #695699. This commit disables the
optimization for expressions of the form '//foo[predicate]'.

xmllint.c | 12 7 + 5 - 0 !
1 file changed, 7 insertions(+), 5 deletions(-)

 xmllint --pretty crashed without following numeric argument

https://bugzilla.gnome.org/show_bug.cgi?id=674789

We need to check for NULL argument before calling atoi()

xmlregexp.c | 8 5 + 3 - 0 !
1 file changed, 5 insertions(+), 3 deletions(-)

 fix potential null pointer dereferences in regexp code

https://bugzilla.gnome.org/show_bug.cgi?id=707749

Fix 3 cases where we might dereference NULL

tree.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 fix a potential null dereference in tree code

https://bugzilla.gnome.org/show_bug.cgi?id=707750

Also reported by Gaurav, simple fix to check the pointer before
dereference

valid.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix pointer dereferenced before null check

for https://bugzilla.gnome.org/show_bug.cgi?id=708364

xmlValidateElementContent is a private function but should still
check the ctxt argument before dereferencing

xzlib.c | 26 22 + 4 - 0 !
1 file changed, 22 insertions(+), 4 deletions(-)

 fix a bug loading some compressed files

For https://bugzilla.gnome.org/show_bug.cgi?id=712528
Related to https://bugzilla.redhat.com/show_bug.cgi?id=877567

There is a bug in xzlib.c which causes certain compressed XML files to fail to
load correctly.  The code in xz_decomp which attempts to verify the checksum
and length of the expanded data fails if the checksum or length at the end of
the file crosses a 1024 byte boundary.  It calls gz_next4 to get those two
values.  This function uses the stream state in state->zstrm, but calls
xz_avail which uses the state->strm stream info.  This causes gz_next4 to
signal a premature EOF if the data it is fetching crosses a 1024 byte boundary.

encoding.c | 16 14 + 2 - 0 !
1 file changed, 14 insertions(+), 2 deletions(-)

 avoid a possibility of dangling encoding handler

For https://bugzilla.gnome.org/show_bug.cgi?id=711149

In Function:
int xmlCharEncCloseFunc(xmlCharEncodingHandler *handler)

If the freed handler is any one of handlers[i] list, then it will make that
hanldlers[i] as dangling. This may lead to crash issues at places where
handlers is read.

tree.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 fix a couple of missing null checks

For https://bugzilla.gnome.org/show_bug.cgi?id=708681

HTMLparser.c | 6 6 + 0 - 0 !
parser.c | 10 10 + 0 - 0 !
2 files changed, 16 insertions(+)

 adding init calls to xml and html read parsing entry points

As pointed out by "Tassyns, Bram <BramT@enfocus.com>" on the list
some call had it other didn't, clean it up and add to all missing
ones

xpath.c | 9 7 + 2 - 0 !
1 file changed, 7 insertions(+), 2 deletions(-)

 handling of xpath function arguments in error case

The XPath engine tries to guarantee that every XPath function can pop
'nargs' non-NULL values off the stack. libxslt, for example, relies on
this assumption. But the check isn't thorough enough if there are errors
during the evaluation of arguments. This can lead to segfaults:

https://mail.gnome.org/archives/xslt/2013-December/msg00005.html

This commit makes the handling of function arguments more robust.

* Bail out early when evaluation of XPath function arguments fails.
* Make sure that there are 'nargs' arguments in the current call frame.

parser.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 missing initialization for the catalog module

catalog.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 fix an fd leak in an error case

valid.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fixing a ptotential uninitialized access

xmlwriter.c | 10 6 + 4 - 0 !
1 file changed, 6 insertions(+), 4 deletions(-)

 fix xmltextwriterwriteelement when a null content is given

xmlmodule.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 avoid a possible null pointer dereference

For https://bugzilla.gnome.org/show_bug.cgi?id=708355

parser.c | 14 14 + 0 - 0 !
1 file changed, 14 insertions(+)

 do not fetch external parameter entities

Unless explicitely asked for when validating or replacing entities
with their value. Problem pointed out by Daniel Berrange <berrange@redhat.com>

xmlmemory.c | 6 4 + 2 - 0 !
1 file changed, 4 insertions(+), 2 deletions(-)

 avoid possible null pointer dereference in memory debug mode

Fix a use before check on pointer
For https://bugzilla.gnome.org/show_bug.cgi?id=729849

xmllint.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 xmllint was not parsing the --c14n11 flag

Cut and paste error, using the wrong variable

parser.c | 13 11 + 2 - 0 !
1 file changed, 11 insertions(+), 2 deletions(-)

 fix regressions introduced by cve-2014-0191 patch

A number of issues have been raised after the fix, and this patch
tries to correct all of them, though most were related to
postvalidation.
https://bugzilla.gnome.org/show_bug.cgi?id=730290
and other reports on list, off-list and on Red Hat bugzilla

HTMLparser.c | 4 2 + 2 - 0 !
SAX2.c | 9 9 + 0 - 0 !
2 files changed, 11 insertions(+), 2 deletions(-)

 adding some missing null checks

in SAX2 DOM building code and in the HTML parser

uri.c | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 xmlsaveuri() incorrectly recomposes uris with rootless paths

For https://bugzilla.gnome.org/show_bug.cgi?id=731063

xmlSaveUri() of libxml2 (snapshot 2014-05-31 and earlier) returns
bogus values when called with URIs that have rootless paths
(e.g. "urx:b:b" becomes "urx://b%3Ab" where "urx:b%3Ab" would be
correct)

relaxng.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 adding a check in case of allocation error

For https://bugzilla.gnome.org/show_bug.cgi?id=733043

There is missing Null condition in xmlRelaxNGValidateInterleave of
relaxng.c
Dereferencing it may cause a crash.

relaxng.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 add a missing argument check

For https://bugzilla.gnome.org/show_bug.cgi?id=733042

the states argument of xmlRelaxNGAddStates() ought to be checked too

relaxng.c | 7 4 + 3 - 0 !
1 file changed, 4 insertions(+), 3 deletions(-)

 add a couple of misisng check in xmlrelaxngcleanuptree

For https://bugzilla.gnome.org/show_bug.cgi?id=733041

check cur->parent before dereferencing the pointer even if
a null parent there should not happen
Also fix a typo

parser.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 fix a potential null dereference

For https://bugzilla.gnome.org/show_bug.cgi?id=733040

xmlDictLookup() may return NULL in case of allocation error,
though very unlikely it need to be checked.

SAX2.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 fix processing in sax2 in case of an allocation failure

Related to https://bugzilla.gnome.org/show_bug.cgi?id=731360

trio.c | 10 8 + 2 - 0 !
1 file changed, 8 insertions(+), 2 deletions(-)

 avoid possible null pointer in trio.c

For https://bugzilla.gnome.org/show_bug.cgi?id=730005
While using assert in libxml2 is really not a good idea, it's
still better to assert than crash

xmlschemastypes.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 check for tmon in _xmlschemadateadd() is incorrect

For https://bugzilla.gnome.org/show_bug.cgi?id=732705
In _xmlSchemaDateAdd(), the check for |tmon| should be the following
since MAX_DAYINMONTH() expects a month in the range [1,12]:

    if (tmon < 1)
	tmon = 1;

Regression introduced in
https://git.gnome.org/browse/libxml2/commit/?id=14b5643947845df089376106517c4f7ba061e4b0

HTMLparser.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 htmlparser: correctly initialise a stack allocated structure
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

If not initialised, the node member remains undefined.

Coverity issue: #60466

https://bugzilla.gnome.org/show_bug.cgi?id=731990

xmlcatalog.c | 11 6 + 5 - 0 !
1 file changed, 6 insertions(+), 5 deletions(-)

 xmlcatalog: fix a memory leak on quit

Coverity issue: #60442

https://bugzilla.gnome.org/show_bug.cgi?id=731990

xmlschemastypes.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 xmlschemastypes: fix potential array overflow

The year and month need validating before being put into the
MAX_DAYINMONTH macro.

Coverity issue: #60436

https://bugzilla.gnome.org/show_bug.cgi?id=731990

relaxng.c | 7 6 + 1 - 0 !
tree.c | 4 4 + 0 - 0 !
2 files changed, 10 insertions(+), 1 deletion(-)

 add couple of missing null checks

For https://bugzilla.gnome.org/show_bug.cgi?id=733710

valid.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 couple of missing null checks

For https://bugzilla.gnome.org/show_bug.cgi?id=734328

Missing Null check could cause crash, if a pointer is dereferenced.

Found problem at two places in valid.c

xmlreader.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 fix enum check and missing break

for https://bugzilla.gnome.org/show_bug.cgi?id=737403

In file xmlreader.c
1. An enum is checked to proper value instead of checking like a boolean.
2. Missing break statement added.

HTMLparser.c | 16 10 + 6 - 0 !
1 file changed, 10 insertions(+), 6 deletions(-)

 possible overflow in htmlparser.c

For https://bugzilla.gnome.org/show_bug.cgi?id=720615

make sure that the encoding string passed is of reasonable size

nanoftp.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 leak of struct addrinfo in xmlnanoftpconnect()

For https://bugzilla.gnome.org/show_bug.cgi?id=732352

in case of error condition in IPv6 support, the early return here
doesn't call freeaddrinfo(result), thus leaking memory.

xmlreader.c | 17 13 + 4 - 0 !
1 file changed, 13 insertions(+), 4 deletions(-)

 pointer dereferenced before null check

For https://bugzilla.gnome.org/show_bug.cgi?id=707027

A few pointer dereference before NULL check fixed.
Removed a useless test

xpointer.c | 28 28 + 0 - 0 !
1 file changed, 28 insertions(+)

 xpointer : fixing null pointers

For https://bugzilla.gnome.org/show_bug.cgi?id=738053
At many places in xpointer.c
Null check is missing which is dereferenced at later places.

xmlmemory.c | 8 5 + 3 - 0 !
1 file changed, 5 insertions(+), 3 deletions(-)

 xmlmemory: handle realloc properly

If realloc fails, free original pointer.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

parser.c | 6 4 + 2 - 0 !
1 file changed, 4 insertions(+), 2 deletions(-)

 fix memory leak xml header encoding field with xml_parse_ignore_enc

When the xml parser encounters an xml encoding in an xml header while
configured with option XML_PARSE_IGNORE_ENC, it fails to free memory
allocated for storing the encoding.
The patch below fixes this.
How to reproduce:
1. Change doc/examples/parse4.c to add xmlCtxtUseOptions(ctxt,
XML_PARSE_IGNORE_ENC); after the call to xmlCreatePushParserCtxt.
2. Rebuild
3. run the following command from the top libxml2 directory:
LD_LIBRARY_PATH=.libs/ valgrind --leak-check=full
./doc/examples/.libs/parse4 ./test.xml , where test.xml contains
following
input:
<?xml version="1.0" encoding="UTF-81" ?><hi/>
valgrind will report:
==1964== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1
==1964==    at 0x4C272DB: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1964==    by 0x4E88497: xmlParseEncName (parser.c:10224)
==1964==    by 0x4E888FE: xmlParseEncodingDecl (parser.c:10295)
==1964==    by 0x4E89630: xmlParseXMLDecl (parser.c:10534)
==1964==    by 0x4E8B737: xmlParseTryOrFinish (parser.c:11293)
==1964==    by 0x4E8E775: xmlParseChunk (parser.c:12283)

Signed-off-by: Bart De Schuymer <bart at amplidata com>

parser.c | 42 38 + 4 - 0 !
1 file changed, 38 insertions(+), 4 deletions(-)

 fix for cve-2014-3660

Issues related to the billion laugh entity expansion which happened to
escape the initial set of fixes

parser.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 fix missing entities after cve-2014-3660 fix

For https://bugzilla.gnome.org/show_bug.cgi?id=738805

The fix for CVE-2014-3660 introduced a regression in some case
where entity substitution is required and the entity is used
first in anotther entity referenced from an attribute value

parser.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch] stop parsing on entities boundaries errors

For https://bugzilla.gnome.org/show_bug.cgi?id=744980

There are times, like on unterminated entities that it's preferable to
stop parsing, even if that means less error reporting. Entities are
feeding the parser on further processing, and if they are ill defined
then it's possible to get the parser to bug. Also do the same on
Conditional Sections if the input is broken, as the structure of
the document can't be guessed.

parser.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 [patch] cleanup conditional section error handling

For https://bugzilla.gnome.org/show_bug.cgi?id=744980

The error handling of Conditional Section also need to be
straightened as the structure of the document can't be
guessed on a failure there and it's better to stop parsing
as further errors are likely to be irrelevant.

buf.c | 43 42 + 1 - 0 !
include/libxml/tree.h | 3 2 + 1 - 0 !
xmlreader.c | 20 19 + 1 - 0 !
3 files changed, 63 insertions(+), 3 deletions(-)

 [patch] cve-2015-1819 enforce the reader to run in constant memory

One of the operation on the reader could resolve entities
leading to the classic expansion issue. Make sure the
buffer used for xmlreader operation is bounded.
Introduce a new allocation type for the buffers for this effect.

parser.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 [patch 1/2] do not process encoding values if the declaration if
 broken

For https://bugzilla.gnome.org/show_bug.cgi?id=751603

If the string is not properly terminated do not try to convert
to the given encoding.

parser.c | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 [patch 2/2] fail parsing early on if encoding conversion failed

For https://bugzilla.gnome.org/show_bug.cgi?id=751631

If we fail conversing the current input stream while
processing the encoding declaration of the XMLDecl
then it's safer to just abort there and not try to
report further errors.