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

Use after free abort on invalid program input #4

Closed
JeanMertz opened this issue Jun 21, 2019 · 2 comments
Closed

Use after free abort on invalid program input #4

JeanMertz opened this issue Jun 21, 2019 · 2 comments
Assignees
Milestone

Comments

@JeanMertz
Copy link
Contributor

While investigating #3, I accidentally used a bad program, which caused the program to crash with a use after free error.

program:

.[] | .hello

input:

[1,2,3]

output:

my_crate-336024fec8446e30(13853,0x7000023d9000) malloc: Incorrect checksum for freed object 0x7f97cdb000d0: probably modified after being freed.
Corrupt value: 0x80000000ffffffff
my_crate-336024fec8446e30(13853,0x7000023d9000) malloc: *** set a breakpoint in malloc_error_break to debug
error: process didn't exit successfully: `/Users/jean/Development/Projects/my_crate/target/debug/deps/my_crate-336024fec8446e30` (signal: 6, SIGABRT: process abort signal)

It doesn't always aobrt (as you might expect with errors like these), sometimes it works as expected:

oarse error: Cannot index number with string \"hello\"
@onelson
Copy link
Owner

onelson commented Jun 22, 2019

I've seen something similar with a simple init then teardown of the jq engine (nothing else). Some times it aborts, sometimes not. This is the sort of thing that makes me entertain the idea of rewriting jq in rust, but the libjq api is undocumented and difficult for me to understand. It would be quite an effort.

Good to have another test case to help pin down the root cause. Thanks for that.

@onelson onelson added this to the v0.3.1 milestone Jun 23, 2019
@onelson
Copy link
Owner

onelson commented Jun 24, 2019

Small update on this. Looks like this is an interaction where the rust is dropping a CString too early causing double free.

I've got some ideas for refactor to hopefully make this sort of bug less likely to show up again, but I'll likely queue those up for v0.4. I should be able to plug this specific case in the short term to finish out 0.3.1. I'd expect it published to crates.io sometime in the next week.

Actually, I'm still digging. The fix I thought was the fix is not the fix. The best clue I have right now is that the jq binary exits with 5 with these inputs, which is JQ_ERROR_UNKNOWN according to the source. This exit code is set during a check for "halted" that my parse implementation doesn't have, so it could be that this is just a branch I never came across and left uncovered as a result.

More in the days to come.

@onelson onelson self-assigned this Jun 24, 2019
onelson added a commit that referenced this issue Jun 30, 2019
onelson added a commit that referenced this issue Jun 30, 2019
thomasmatecki pushed a commit to thomasmatecki/jq-rs that referenced this issue May 7, 2021
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