Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSS-Fuzz issue 65950 #1124

Closed
oss-fuzz-robot opened this issue Jan 19, 2024 · 4 comments
Closed

OSS-Fuzz issue 65950 #1124

oss-fuzz-robot opened this issue Jan 19, 2024 · 4 comments
Assignees

Comments

@oss-fuzz-robot
Copy link

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 johnbartholomew self-assigned this Feb 7, 2024
@johnbartholomew
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@oss-fuzz-robot
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants