Ah, I've been hitting it constantly with libFuzzer in a slightly different form: 
==11961==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000b60fa1 at pc 0x00000099b4f1 bp 0x7ffde259e3d0 sp 0x7ffde259e3c8
READ of size 1 at 0x000000b60fa1 thread T0
    #0 0x99b4f0 in xmlNextChar parserInternals.c:535:13
    #1 0x5769e1 in xmlParseDocument parser.c:10880:6
    #2 0x5a0575 in xmlDoRead parser.c:15390:5
    #3 0x5a0a50 in xmlReadMemory parser.c:15476:13
    #4 0x4df7bb in LLVMFuzzerTestOneInput (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0x4df7bb)
    #5 0xb264c5 in fuzzer::SimpleUserSuppliedFuzzer::TargetFunction(unsigned char const*, unsigned long) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb264c5)
    #6 0xb336bf in fuzzer::Fuzzer::ExecuteCallback(std::vector<unsigned char, std::allocator<unsigned char> > const&) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb336bf)
    #7 0xb23788 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb23788)
    #8 0xb2410c in fuzzer::FuzzerDriver(std::vector<std::string, std::allocator<std::string> > const&, fuzzer::UserSuppliedFuzzer&) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb2410c)
    #9 0xb238d6 in fuzzer::FuzzerDriver(int, char**, fuzzer::UserSuppliedFuzzer&) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb238d6)
    #10 0xb2381a in fuzzer::FuzzerDriver(int, char**, int (*)(unsigned char const*, unsigned long)) (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb2381a)
    #11 0xb3f450 in main (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0xb3f450)
    #12 0x7f76d7127ec4 in __libc_start_main /tmp/tmp.Htw1L27e9P/csu/libc-start.c:287
    #13 0x41be75 in _start (/usr/local/google/home/kcc/fuzz/libxml/libxml_fuzzer+0x41be75)

0x000000b60fa1 is located 63 bytes to the left of global variable '<string literal>' defined in 'parser.c:3131:8' (0xb60fe0) of size 40
  '<string literal>' is ascii string 'Name %s is not XML Namespace compliant
'
0x000000b60fa1 is located 0 bytes to the right of global variable '<string literal>' defined in 'parser.c:3115:33' (0xb60fa0) of size 1
  '<string literal>' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow parserInternals.c:535:13 in xmlNextChar

Created attachment 319996 [details]
repro

[moved from bug 756525, where I originally put this comment in error]

I could still reproduce both errors, so I bodged a couple of fixes to unblock Kostya's fuzzer (although I don't think the parserInternals.c change is correct):


diff --git a/parser.c b/parser.c
index c5741e3..117e9c5 100644
--- a/parser.c
+++ b/parser.c
@@ -12672,6 +12672,7 @@ xmlHaltParser(xmlParserCtxtPtr ctxt) {
        }
        ctxt->input->cur = BAD_CAST"";
        ctxt->input->base = ctxt->input->cur;
+       ctxt->input->end = ctxt->input->cur + 1;
     }
 }

diff --git a/parserInternals.c b/parserInternals.c
index 2b8646c..e18c76c 100644
--- a/parserInternals.c
+++ b/parserInternals.c
@@ -532,8 +532,13 @@ xmlNextChar(xmlParserCtxtPtr ctxt)
             ctxt->input->col++;
         ctxt->input->cur++;
         ctxt->nbChars++;
-        if (*ctxt->input->cur == 0)
+        if ((ctxt->input->cur >= ctxt->input->end) ||
+            (*ctxt->input->cur == 0))
             xmlParserInputGrow(ctxt->input, INPUT_CHUNK);
+        if (ctxt->input->cur >= ctxt->input->end) {
+          xmlPopInput(ctxt);
+          return;
+        }
     }
     if ((*ctxt->input->cur == '%') && (!ctxt->html))
         xmlParserHandlePEReference(ctxt);

Created attachment 320476 [details]
c01_id0051.min

Test case c01_id0051.min from Comment #0.

  Thanks David,

but the proper fix is not not skip the undetected '>' at the end of the
internal subset and return directly in case of error. Patch commited:

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

Daniel

Hi Daniel

Has a CVE been requested for this issue? (or not worth of?). The commit a7a94612aa3b16779e2c74e1fa353b5d9786c602 references #759671.

Regards,
Salvatore

Hi

To avoid confusions I suggest to open/unembargo this one. The reason is that the commit references to 759671. But already distributions have CVE-2016-1762 marked as "Apple specific", e.g. https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-1762.html

Regards,
Salvatore

(In reply to Salvatore Bonaccorso from comment #7)
> Hi
> 
> To avoid confusions I suggest to open/unembargo this one. The reason is that
> the commit references to 759671. But already distributions have
> CVE-2016-1762 marked as "Apple specific", e.g.
> https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-1762.html
> 
> Regards,
> Salvatore

This issue is not Apple-specific; the CVE-ID was just assigned from Apple's pool because you requested one.

*** Bug 751643 has been marked as a duplicate of this bug. ***

Removing security group as commit is public.

*** Bug 758549 has been marked as a duplicate of this bug. ***

*** Bug 756525 has been marked as a duplicate of this bug. ***