parse_glob fails when the input of ^] is very large - OSS-Fuzz issue 64502

[oss-fuzz-robot]

OSS-Fuzz has found a bug in this project. Please see https://oss-fuzz.com/testcase?key=5339499714183168 for details and reproducers.

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64502 and will auto-close if the status changes there.

If you have trouble accessing this report, please file an issue at https://github.com/google/oss-fuzz/issues/new.

[sylvestre]

when the input of the function is 174571 times ^[, it freezes
To reproduce:

printf '^[%.0s' {1..174571} > output.txt   
 ./target/x86_64-unknown-linux-gnu/release/fuzz_parse_glob -rss_limit_mb=2560 -timeout=60 -runs=100  output.txt

[sylvestre]

probably in this function:

coreutils/src/uucore/src/lib/parser/parse_glob.rs

Line 13 in 177ac7e

fn fix_negation(glob: &str) -> String {

[cj-zoltan-kiss]

I'm looking into this at the moment, on question which came up: when that function finds a [^ pattern, it starts to look for the closing ]. But this doesn't take into account that there could be an another [^ in inside, and that closing ] belongs to that. Or is that allowed at all? If not, we can just ignore this situation and allow the caller to detect this error. I couldn't dig out the spec, maybe you can point me to the right direction?

[cj-zoltan-kiss]

Looking at it more there is a trivial fix: if we doesn't find any ], we can break the loop as there is no point looking for it again. I'll post a patch for that.

[cj-zoltan-kiss]

Btw. if I omit the timeout, the test completes after ~4 hours with the original code ...

[sylvestre]

ah ah, fun fact, thanks :)

[cj-zoltan-kiss]

And looking at it again it made me think: why do we look for the closing ] at all? If it's not there, whoever parses the glob will throw an error when it notices this. Or is there a case of the [^ character sequence, where we shouldn't replace the ^ with !?