[zayeem06]

S_parser_feed dereferences the first byte of an incoming chunk to detect an LF that continues a CR from the previous chunk, before it has established that the chunk is non-empty, so a streaming caller that hands cmark_parser_feed a zero-length chunk gets a one-byte read past the end of its buffer (ASan reports a heap-buffer-overflow at blocks.c:591). That same path then clears last_buffer_ended_with_cr unconditionally, so an empty chunk arriving between a trailing CR and a leading LF is enough to split one paragraph into two.

Returning early when len == 0 fixes both symptoms at the point where the chunk length is known, rather than asking callers to filter empty chunks. Worth verifying: the new api_test case allocates its chunk at exactly 6 bytes so the overflow is caught by the ASan jobs, and it also fails as a plain assertion in the non-sanitizer builds because the paragraph splits.