Yang, this looks like something for you (null-deref in property class name parsing).

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Issue 915184 has been merged into this issue.

ClusterFuzz has detected this issue as fixed in range 616877:616900.

Detailed report: https://clusterfuzz.com/testcase?key=5156161688698880

Fuzzer: afl_v8_regexp_builtins_fuzzer
Fuzz target binary: v8_regexp_builtins_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  v8_regexp_builtins_fuzzer
  v8::internal::RegExpParser::ParsePropertyClassName
  v8::internal::RegExpParser::ParseDisjunction
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=616454:616490
Fixed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=616877:616900

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5156161688698880

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5156161688698880 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Looking at the stack trace and the location of the crash, I think this may have been some sort of false positive and issue with ASAN instrumentation rather than bug in the regexp parser. It also went away by itself.