Keep an incremental count of open block types #471
Conversation
|
Out of interest, I'm surprised that the checks ran automatically. I'm a first-time contributor to cmark, so normally would have to wait for approval to run the checks. Have you modified something in the settings to allow the checks to run for first-time contributors? |
|
This fix is incomplete. Please don't merge yet. @kevinbackhouse See my report at HackerOne. |
|
Yes, I've modified the settings so that no approval is needed except for new GH-ers. |
|
I haven't seen the HackerOne report yet (I'm not on the team that has access), but I've independently figured out what the problem is. I think it means that this strategy of counting the number of open blocks won't work, and we have to go back to the original solution of putting an arbitrary limit on the nesting depth. |
This is a rebase of the solution that we implemented in cmark-gfm to fix GHSA-66g8-4hjf-77xh.
The idea is to incrementally keep an up-to-date count of the number of "open" blocks, categorized by node type, so that the loop in
check_open_blockscan bail out early when it can see from the counts that the rest of the list doesn't contain any nodes that need to be checked.I've fuzzed this solution extensively on cmark-gfm, but not on cmark.
Reproduction steps for the bug that this PR fixes:
Increasing the number 10000 in the above command causes the running time to increase quadratically.