str2tag_core is recursive (one frame per character), so a long runtime
input such as a fuzzer-supplied Content-Type would overflow the stack.
Rewrite the runtime entry point str2tag() iteratively while keeping the
recursive constexpr str2tag_core for compile-time UDL evaluation. The
hash output is unchanged for all inputs.
Same root cause as #508342856 (fixed in 2d2efe4): an oversized
Content-Length value (here 4467440718547775) caused res.body.reserve()
to attempt a multi-petabyte allocation. The UBSAN fuzzer job surfaced
it as a std::bad_alloc-driven abort, while the ASAN job for #508342856
reported it as allocation-size-too-big. The payload_max_length_ cap
introduced in 2d2efe4 already addresses both.
A malicious or malformed server response with an enormous Content-Length
header (e.g. 20000000000) caused the client to call res.body.reserve(len)
with the untrusted value, triggering OOM before read_content's
payload_max_length_ check could take effect. Cap the pre-reservation
at payload_max_length_, since reading more than that is never useful.
* *Add server fuzzer target and seed corpus
* Add fuzz_test option to Makefile
* Fix#685
* Try to fix Github actions on Ubuntu
* Added ReadTimeoutSSL test
* Comment out `-fsanitize=address`
* Rebase upstream changes
* remove address sanitizer temporarily
* Add separate Makefile for fuzzing
* 1. Remove special char from dictionary
2. Clean fuzzing/Makefile
* Use specific path to avoid accidently linking openssl version brought in by oss-fuzz
* remove addition of flags
* Refactor Makefile
* Add missing newline
* Add fuzztest to github workflow
* Fix
Co-authored-by: yhirose <yuji.hirose.bug@gmail.com>
