Stack overflow in org.joni.Parser recursive parse cycle

[fuyu0425]

Hello Joni maintainers,

I am reporting a reproducible failure: Stack overflow in org.joni.Parser recursive parse cycle. I reproduced it by replaying the attached testcase input.txt against a locally built OSS-Fuzz address-sanitized target RegexMatcherFuzzer for project joni.

I am sending this as a public issue because the currently validated evidence is limited to a reproduced OSS-Fuzz crash, and I have not separately validated release-build behavior or broader security impact.

Tested scope

• Reproduced on a locally built OSS-Fuzz target for project joni.
• Target name: RegexMatcherFuzzer.
• Upstream repository associated with the OSS-Fuzz project: https://github.com/jruby/joni.
• This draft represents one grouped root-cause bucket built from 13 signature-deduped replay entries.
• Released versions were not separately validated.

Observed result

• Reproduced against OSS-Fuzz target RegexMatcherFuzzer with sanitizer address.
• Observed crash: == Java Exception: com.code_intelligence.jazzer.api.FuzzerSecurityIssueLow: Stack overflow (use '-Xss921k' to reproduce).
• First relevant application frame: org.joni.Parser.parseSubExp.
• Replay exit code: 77.
• This root-cause bucket currently groups 13 signature-deduped replay findings covering 16 original source POV entries.

Likely trigger / root cause

• This draft groups findings by the first relevant application frame observed in the reproduced crash: org.joni.Parser recursive parse cycle.
• Across the grouped members, the stack trace rotates through org.joni.Parser.parseEnclose, parseExp, parseBranch, and parseSubExp, which is why these signatures were merged into one parser-cycle report.
• That grouping is a reporting convenience heuristic, not a fully proven shared root cause.

Current validated impact

• This report currently establishes only the reproduced behavior in the OSS-Fuzz address-sanitized target.
• I have not separately validated the same behavior in release builds or non-fuzz entrypoints.
• I have not established memory corruption or broader security impact beyond process crash / stack exhaustion.

Exact repro

1. Clone google/oss-fuzz.
2. Run the attached helper script with the OSS-Fuzz checkout and the attached testcase:

./repro-command.sh /path/to/oss-fuzz input.txt

The helper script builds the address-sanitized target and runs infra/helper.py reproduce joni RegexMatcherFuzzer.

Expected result

• The run reproduces == Java Exception: com.code_intelligence.jazzer.api.FuzzerSecurityIssueLow: Stack overflow (use '-Xss921k' to reproduce).
• The trace includes org.joni.Parser.parseSubExp.

Attachments

• input.txt
• repro-command.sh

[headius]

Thank you for the report. It would be interesting to see if this case affects the regex parser in standard Ruby, since this one is mostly a port of that code.

[fuyu0425]

I checked this on stock CRuby outside the fuzz harness.

I took the same parser input derived from the testcase and also tried the simplified
form (?u: repeated 3000 times. On Ruby 3.2, 3.3, and 3.4, Regexp.new(...) does not
reproduce the Joni stack overflow for me. MRI rejects it immediately with a normal
RegexpError about an unmatched parenthesis.

I also pushed the nesting much higher on Ruby 3.4 (30000 and 100000 repeats) and
still got RegexpError, not a stack overflow.

So at least from this case, I’m not seeing the same behavior on standard Ruby.

[headius]

Aha, I wonder if they patched something to prevent this case. We can compare our parsers and probably find the difference quickly. Thank you for verifying!