Predator and CL could not provide any possible suspects.
Using Code Search for the file, "pdf_jpx_fuzzer" assigning to concern owner.

Suspecting Commit#
https://pdfium.googlesource.com/pdfium.git/+/b0860beccd6a4a8d9f8ea3dbba392a3a13218ad3

@thestig -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This is in a opj_j2k_decode() call inside CJPX_Decoder::Init(), which is the first thing the JPX fuzzer calls via CreateDecoder(). Digger deeper, there's a 5 level for-loop in opj_tcd_init_tile() that does a lot of memory allocation.

#2  opj_tcd_init_tile()
#3  opj_tcd_init_decode_tile()
#4  opj_j2k_read_tile_header()
#5  opj_j2k_decode_tiles()
#6  opj_j2k_exec()
#7  opj_j2k_decode()

But in a timely manner, https://pdfium-review.googlesource.com/12770 upgraded OpenJPEG today, and now it looks like this problem went away?! CF can probably verify this is fixed in a day or two.

ClusterFuzz has detected this issue as fixed in range 499690:499770.

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

Fuzzer: libFuzzer_pdf_jpx_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  pdf_jpx_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=395689:395794
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=499690:499770

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

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

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

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