[Enhancement] Mutator which replaces ASCII digits with non-ASCII ones #1068

Background

The method java.lang.Character#digit and related number parsing methods which rely on it (e.g. Integer#parseInt, BigDecimal(String)) not only allow ASCII digits but also other Unicode digits, e.g. Integer.parseInt("١၂꘣４") == 1234.

However, often these methods are used by parsing libraries which implement some specification, and that specification normally only allows ASCII. By accepting non-ASCII input they could allow 'parser differentials' exploits, or might cause bugs when code erroneously assumes the digit can only be ASCII and therefore has a certain string encoding size, e.g. 1 byte.

Here are a few examples where this incorrect behavior was fixed:

• apache/commons-validator@d5b2aa7
• apache/commons-lang@7b236d4
• openjdk/jdk@cdc1582

Detection of such bugs with a fuzzer might be a bit limited (e.g. when the fuzzed code consistently erroneously accepts the non-ASCII digits), but it could still help when:

• the non-ASCII digits then cause subsequent bugs, e.g. exceptions due to unexpected encoded string size
• when using the fuzzer for 'differential fuzzing / testing' against another library which does reject non-ASCII digits

Suggested enhancement

Maybe there could be a mutator which rarely replaces ASCII digits 0-9 in the input with corresponding non-ASCII digits. For those non-ASCII digits maybe it would make sense to randomly choose between multiple variants with different encoding length, e.g.:

• U+661 - U+0669 (non-ASCII digits with lowest code point)
• U+FF11 - U+FF19 (non-ASCII digits near U+FFFF)
• U+1FBF1 - U+1FBF9 (non-ASCII supplementary codepoints)
  (they were only added in 2024 though, so maybe too 'new' still? alternatively could use U+1E951 - U+1E959)

What do you think? Does this make sense as a mutator?
Or does this already exist as part of libFuzzer or Jazzer and I overlooked it?