@jshin, this would appear to be upstream in ICU itself, as that is the library under test.  It is unclear whether this condition can actually be triggered in chromium itself, in which case it would be serverity none.  Leaving at high for the moment out of an abundance of caution.  Thanks!

jshin: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

jshin: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This uses the same invalid UTF-8 input as  bug 662832 . And, for the same reason as  bug 662832  is not a high priority, this bug is not. 

1. The API being tested is not used by Chrome/v8/Blink.
2. Chrome/v8/Blink would not feed invalid UTF-8 input. 

+aheninger, mscherer : FYI 

libfuzz needs a way to generate valid (but random) UTF-8 or UTF-16 input strings to test ICU. Where can I file a FR against libfuzz? 

Removing security flags based on #8. If you want to only feed valid UTF-8 or UTF-16 strings to the target function, then it would have to be done in the fuzzing stub (https://cs.chromium.org/chromium/src/third_party/icu/fuzzers/icu_ucasemap_fuzzer.cc)

ClusterFuzz has detected this issue as fixed in range 471616:471627.

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

Fuzzer: libfuzzer_radamsa_icu_ucasemap_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Heap-buffer-overflow WRITE 1
Crash Address: 0x615000001160
Crash State:
  utf8TextAccess
  utext_setNativeIndex_56
  icu_56::RuleBasedBreakIterator::first
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=397702:398136
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=471616:471627

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


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 6083453533814784 is verified as fixed, so closing issue.

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