coreutils
coreutils copied to clipboard
parse_glob fails when the input of ^] is very large - OSS-Fuzz issue 64502
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.
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
probably in this function: https://github.com/uutils/coreutils/blob/177ac7ea287394ad876f5848ff670ea1da413124/src/uucore/src/lib/parser/parse_glob.rs#L13
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?
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.
Btw. if I omit the timeout, the test completes after ~4 hours with the original code ...
ah ah, fun fact, thanks :)
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 !?
OSS-Fuzz has closed this bug. Please see https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64502 for details.