Disclosure: my real motivation is to provide even more ammunition for #32424. But this issue is still valid and represents also a DOS and possibly other security vulnerability.

The Redcarpet-based wiki formatter is shared in Redmine, see source:trunk/lib/redmine/wiki_formatting/markdown/formatter.rb. I guess that with Rails 5 on Redmine 4, multithreaded operation became available by default. And when the app server supports multithreading, it just happens that Redmine is multithreaded (not a Rails expert). Redcarpet instance is not thread-safe - I've found "this issue":https://github.com/vmg/redcarpet/issues/570, opened for more than three years atm.

Steps to reproduce:

• @docker run redmine4@ Note[1]
• Configure markdown as rext formatting, create some larger wiki pages, create an API key
• Run a stress test with parallel requests, we were using 12 workers invoking @curl -sf -g -H "X-Redmine-API-Key: $api_key" -o "$o" "$url/$q"@

fn1. Yes, it's using not recommended Webrick within @rails server@, still hope it's not an excuse for this behavior. :) Actually, we first came across this when creating a rake task for processing markup format conversions in parallel. But it happened also when we were doing rendering tests using standard Redmine stack, which is this issue.

Expected result: everything is rendering fine.

Actual result: ruby segfaults after a few hundred pages rendered.

ruby: markdown.c:2896: sd_markdown_render: Assertion `md->work_bufs[BUFFER_SPAN].size == 0' failed.
/usr/src/redmine/lib/redmine/wiki_formatting/markdown/formatter.rb:82: [BUG] Segmentation fault at 0x0000000000000000
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]

Possible solutions:

• Do not share Redcarpet formatter
• Mutex it
• Make it thread local
• Document that multithreaded operation must be prevented when Markdown is used
• Get rid of Redcarpet (yes, please! Plus #32424)