For https://bugzilla.gnome.org/show_bug.cgi?id=672539
Reported by Axel Miller <axel.miller@ppi.de>
Consider the following start-tag:
<x xmlns=""version="">
The start-tag does not conform to the rule
[40] STag ::= '<' Name (S Attribute)* S? '>'
since there is no whitespace in front of the attribute "version".
Thus, libxml2 should reject the start-tag.
But it doesn't:
$ echo '<x xmlns=""version=""/>' | xmllint -
<?xml version="1.0"?>
<x xmlns="" version=""/>
The error seems to happen only if there is a namespace declaration in
front of
the attribute. A missing whitespace between other attributes is handled
correctly:
$ echo '<x someattr=""version=""/>' | xmllint -
-:1: parser error : attributes construct error
<x someattr=""version=""/>
^
[...]
For https://bugzilla.gnome.org/show_bug.cgi?id=734280
libxml2 reports wrong error column numbers (field int2 in xmlError)
in structured error handler, after parsing XML attribute values.
Example XML:
<?xml version="1.0" encoding="UTF-8"?>
<root
xmlns="urn:colbug">&</root>
<!--
1 2 3 4
1234567890123456789012345678901234567890
-->
Expected location of the error would be line 3, column 21.
The actual location of the error is line 3, column 9:
$ ./xmlparse colbug2.xml
colbug2.xml:3:9: xmlParseEntityRef: no name
The 12 characters of the xmlns attribute value "urn:colbug" are
not accounted for in the error column value.
For https://bugzilla.gnome.org/show_bug.cgi?id=734276
libxml2 reports wrong error column numbers (field int2 in xmlError)
in structured error handler, after an XML declaration containing
whitespace.
Example XML:
<?xml version="1.0" encoding="UTF-8" ?><root>&</root>
<!--
1 2 3 4 5 6
123456789012345678901234567890123456789012345678901234567890
-->
Expected location of the error would be line 1, column 53.
The actual location of the error is line 1, column 44:
$ ./xmlparse colbug1.xml
colbug1.xml:1:44: xmlParseEntityRef: no name
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
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
The switch to xzlib had for consequence that the compression
level of the input was not gathered anymore in ctxt->input->buf,
then the parser compression flags was left to -1 and propagated
to the resulting document.
Fix the I/O layer to get compression detection in xzlib,
then carry it in the input buffer and the resulting document
This should fix
https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3456
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.
If entities expansion in the XML parser is asked for,
it is possble to craft relatively small input document leading
to excessive on-the-fly content generation.
This patch accounts for those replacement and stop parsing
after a given threshold. it can be bypassed as usual with the
HUGE parser option.
https://bugzilla.gnome.org/show_bug.cgi?id=692915
the new set of converting functions tried to limit the encoding
conversion of the raw buffer to the consumption one to work in
a more progressive fashion. Unfortunately this was bad for
performances and led to errors on progressive parsing when
a very large chunk was close to the end of the document. Fix
the new internal function and switch back to the old way of
converting. Fix another bug in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=690202
Buffer overflow errors originating from xmlBufGetInputBase in 2.9.0
The pointers from the context input were not properly reset after
that call which can do reallocations.
Related to https://bugs.launchpad.net/lxml/+bug/502959
Basically the core of the issue is that if an entity references another
entity, then in case we are replacing entities content, we should always
do so by copying the referenced content as long as the reference is
done within the entity. Otherwise, if for some reason there is a later
parsing error that entity content may be freed.
Complex scenario exposed by command:
thinkpad:~/XML/diveintopython-5.4/xml -> valgrind --db-attach=yes
../../xmllint --loaddtd --noout --noent diveintopython.xml
Document references &a;
a references &b;
we references b content directly in by linking in the a content
a has an error further down
we free a, freeing the chunk from b
Document references &b; after &a;
we try to copy b content, but it was freed already => segfault
* parser.c: never reference directly entity content without copying if
we aren't in the document main entity
Fix the lack of line number as reported by Johan Corveleyn <jcorvel@gmail.com>
* parser.c include/libxml/parser.h: add an XML_PARSE_BIG_LINES parser
option not switch on by default, it's an opt-in
* SAX2.c: if XML_PARSE_BIG_LINES is set store the long line numbers
in the psvi field of text nodes
* tree.c: expand xmlGetLineNo to extract those informations, also
make sure we can't fail on recursive behaviour
* error.c: in __xmlRaiseError, if a node is provided, call
xmlGetLineNo() if we can't get a valid line number.
* xmllint.c: switch on XML_PARSE_BIG_LINES in xmllint
That condition is one raised when the parser should positively stop
processing further even to report errors. Best is to test is after
most GROW call especially within loops
Those can be overrided by the XML_PARSE_HUGE option, they
are just default limits for Name lenght, dictionary size limits
and maximum amount of parser lookup.
* include/libxml/parserInternals.h: define the limits
* include/libxml/xmlerror.h: add a new error
* parser.c parserInternals.c: implements the new limits
Unless the XML_PARSE_HUGE option is given to the parser,
the value is XML_MAX_TEXT_LENGTH, i.e. the same than for a
text node within content.
Also cleanup some unsigned int used for memory size.
Unless the XML_PARSE_HUGE option is given to the parser,
the value is XML_MAX_TEXT_LENGTH, i.e. the same than for a
text node within content.
Also cleanup some unsigned int used for memory size.
When calling xmlParserInputBufferPush, the buffer may be reallocated
and at the input level the pointers for base, cur and end need to
be reevaluated.
* buf.c buf.h: add two new functions, one to get the base from the
input of the buffer, and another one to reset the pointers based
on the cur and base inded
* HTMLparser.c parser.c: cleanup to use the new helper functions
as well as making sure size_t is used for the indexes computations
This was scattered in a number of modules, xmlParserInputPtr
have usually their base, cur and end pointer set from an
xmlBuf used as input.
* buf.c buf.h: add a new function implementing this setup
* parser.c HTMLparser.c catalog.c parserInternals.c xmlreader.c
use the new function instead of digging into the buffer in
all those modules
