CVE-2017-5969 has been assigned to this issue by MITRE. Their comments below:

This appears to be a valid vulnerability but we do not consider
"Someone runs xmllint --recover crash-libxml2-recover.xml" a valid
attack vector. With that attack vector, an end user experiences a loss
of functionality after the xmllint command-line tool crashes with a
NULL pointer dereference (because the end user can completely work
around this by not repeating the specific command-line invocation,
there would be no security impact).

The security problem is that xmlSaveDoc (shown in the
http://www.openwall.com/lists/oss-security/2016/11/05/3 post) is a
supported part of the libxml2 API. At least in theory, any arbitrary
application may choose to call xmlSaveDoc, and the NULL pointer
dereference could be a remote denial of service for that application.

The http://www.openwall.com/lists/oss-security/2016/11/05/3 post also
mentions "It is interesting to note that the developers of libxml2
strongly recommend not to use recover mode to parse untrusted inputs."
As far as we can tell, the affected code for this vulnerability is
reachable even when "recover mode" is not used. The "recover mode"
option primarily affects the code behavior within the parser.c file.
As shown in the
http://www.openwall.com/lists/oss-security/2016/11/05/3 post, none of
the parser.c code is called during processing of the input in
question.

Smaller repro:
<!DOCTYPE[<!ELEMENT d(a,()>

Not sure if I agree with MITRE's assessment here.

As far as I can tell, the null ptr dereference in xmlSaveDoc is only possible when it is called with a non-well-formed xmlDocPtr.  Such an xmlDocPtr will only be constructed by libxml's parsers if XML_PARSE_RECOVER is set.

As noted in the original report, it is "strongly recommended not to use" XML_PARSE_RECOVER for any applications parsing untrusted input.  Thus, for an application to be vulnerable it would have to be modifying parts of the xmlDocPtr structure directly in a dangerous way prior to calling xmlSaveDoc.

In particular, the final statement is false:

> none of the parser.c code is called during processing of the input in question.

This can be trivially verified by running the reproducer in gdb, with a breakpoint on xmlDoParse, and seeing that ctxt->options&XML_PARSE_RECOVER and ctxt->recovery are set.


I think that an application calling xmlSaveDoc() with a malformed document structure constitutes API abuse, and probably doesn't warrant a CVE.

This is also a dupe of:

Bug 758422: xmllint: null ptr deref + segfault in xmlDumpElementContent at valid.c:1181
<https://bugzilla.gnome.org/show_bug.cgi?id=758422>

I'm pretty sure the patch on that bug will fix this issue.

*** This bug has been marked as a duplicate of bug 758422 ***

And I would disagree of a CVE with the Recover parsing option which should
only be used for manual recovery at least for XML parser.

Daniel

I don't have access to bug 758422. Is the mentioned patch for that bug applied to git master? if so, which is the commit?

Thanks!

Fixed with the following commit:

https://git.gnome.org/browse/libxml2/commit/?id=94691dc884d1a8ada39f073408b4bb92fe7fe882