Its a timeout issue in the the decoder fuzzer, on x86_32
It seems we haven't sufficiently constrained this fuzzer enough for 32 builds to avoid timeout issues.
Though, looking at the fuzzer code, it appears we never actually limited the size of the input data
Suggest adding a check for len <= 2048 ( or some other appropriate value) to return 0 in the event that limit is exceeded
### Tasks
- [ ] download the fuzzer corpus that reproduced the crash
- [ ] reproduce the problem locally
- [ ] add a length check to the decoder test
- [ ] confirm the timeout is avoided
We have a new clusterfuzz report:
https://oss-fuzz.com/testcase-detail/6423842793783296
Its a timeout issue in the the decoder fuzzer, on x86_32
It seems we haven't sufficiently constrained this fuzzer enough for 32 builds to avoid timeout issues.
Though, looking at the fuzzer code, it appears we never actually limited the size of the input data
Suggest adding a check for len <= 2048 ( or some other appropriate value) to return 0 in the event that limit is exceeded