Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Infinite loop in Parser#next_block #2888
This is another bug found with the fuzzer. With specific input it's possible to cause an inifinite loop in the
I think this bug should be prioritized since it can cause a denial of service in programs that rely on asciidoctor. Specifically GitHub is safe since it uses aggressive timeouts in its markup process, although I did later get a 500 error on the GitHub main page for a few hours that I've never seen before. I can't tell if it's related or not.
For the record, the infinite loop is not in Parser.next_block, and thus not related to the aforementioned while loop. The infinite loop is in Parser.parse_list_item. The method expects Parser.next_block to eventually consume all lines, but due to this bug, the lines are never exhausted.
added a commit
Oct 20, 2018
I want to challenge the statement in the CVE that Asciidoctor misuses the
As I explained above, the infinite loop was actually coming from a different while loop. In particular, this one: https://github.com/asciidoctor/asciidoctor/blob/v126.96.36.199/lib/asciidoctor/parser.rb#L1342-L1346
The infinite loop was caused by the fact that Parser.next_block was not exhausting all the lines in the reader as the while loop expected it would. This was happening because the regular expression that detects any list was not agreeing with the regular expression that detects a specific list type. So the line kept getting pushed back onto the reader, hence causing the loop.
@mojavelinux I am sorry for having mislead you with the explanation. When I manually killed the execution few times I was stopped at Parser.next_block so I made the faulty conclusion that the bug is in this method. This may have took you some time debugging the wrong thing
The CVE was supposed to be reserved until the issue was closed. I'll request to have its description corrected ASAP using your explanation in the above comment, plus indicate the fixed version.
Thank you for solving this so quickly (and all other bugs too, but taking care of this one seriously given I didn't have a good solution or explanation).
@zelivans You're welcome. And thank you. I want you to know that I am very grateful that you discovered and reported this issue. Trust me, your report didn't lead me astray at all. Even though the problem turned out to be on a different line than you suggested, it was still in the same vicinity, which allowed me to track it down quickly. I only pointed out the distinction in an effort to provide as much information as possible for the report. So there's no reason to be