Skip to content

Fix mbregex fuzzer not being built and truncating its input - #24720

Open
yumasansansan wants to merge 1 commit into
php:masterfrom
yumasansansan:fuzzer-mbregex-fixes
Open

yumasansansan wants to merge 1 commit into
php:masterfrom
yumasansansan:fuzzer-mbregex-fixes

Conversation

@yumasansansan

Copy link
Copy Markdown
Contributor

Two problems in the mbregex fuzzer:

  1. sapi/fuzzer/config.m4 builds php-fuzz-mbregex only if test -n "$enable_mbregex". Because sapi/*/config.m4 is evaluated before ext/*/config.m4, PHP_MBREGEX is not known yet, and enable_mbregex is only set if --enable-mbregex/--disable-mbregex is given on the command line. With ./configure --enable-fuzzer --enable-mbstring (as documented in the README), mbregex is compiled in (HAVE_MBREGEX is defined), but php-fuzz-mbregex is not built.
  2. fuzzer_call_php_func() creates the arguments with ZVAL_STRING(), i.e. strlen(), so the pattern and subject end at the first NUL byte, and the part of the input space containing NUL bytes was never passed to Oniguruma. The fuzzer now passes the input with its length. For the input a\0b, onig_new() now receives a 3 byte pattern.

The input format is unchanged, existing corpora stay valid.

The mbregex fuzzer was only built if --enable-mbregex was passed
explicitly. SAPIs are configured before extensions, so only
enable_mbregex is available here, and it is unset unless the option is
given, although mbregex is enabled by default together with mbstring.

The fuzzer also passed its input through strlen(), dropping everything
after the first NUL byte, although mb_ereg() accepts NUL bytes in both
the pattern and the subject.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant