OSS-Fuzz issue 65950

[oss-fuzz-robot]

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

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65950 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.

[johnbartholomew]

Building with -fsanitize=address I can reproduce this (with the test case from oss-fuzz). However, building _without) -fsanitize=address I instead correctly get a safe vm runtime max stack frames exceeded error. That is, the VM is tracking its stack depth and quits safely. Whether this is a problem in practice would, I assume, depend on the actual max stack depth of the environment that jsonnet is running in / has been built with.

[johnbartholomew]

This can be reproduced with a smaller test input:

./jsonnet -e "{ x: $ { y: $ } + '' }"

Setting --max-stack to a lower value (the default is 500) prevents the AddressSanitizer stack overflow, catching the problem in the jsonnet vm. For me on the computer I'm sitting at right now, with the compiler and build settings I'm using right now, a value of 331 catches the problem, 332 crashes.

./jsonnet --max-stack 331 -e "{ x: $ { y: $ } + '' }"

Perhaps the default stack limit should be reduce to ~200 or something that is a little "safer". Alternatively perhaps we can detect infinite recursion somehow (maybe tricky), or we would need to do some probably significant code restructuring to go from a recursive formulation to a non-recursive structure.

If we just want to make the fuzzer happy we can probably adjust the stack limit just in the fuzz wrapper, without actually changing the default limit. That feels a little like cheating though.

[johnbartholomew]

#1142 is one possible approach to prevent this particular stack overflow.

[oss-fuzz-robot]

OSS-Fuzz has closed this bug. Please see https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65950 for details.