-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
http2.c: ASSERT: len >= stream->upload_blocked_len #11500
Comments
@icing this assert seems to have code handling the case in run-time just following it, so I'm not sure about the importance of this trigger. What do you think? |
@bagder when writing this, I assumed that subsequent calls would satisfy the assertion. But, given the complexity of the transfer handling, I was not 100% sure. So, my question would be: is the situation triggered by OSSFuzz also part of "normal" behaviour that we just do not see regularly? How does it trigger? |
Architecture is i386. Test case it fails on is like this: TLVHeader(type='Server response 9' (25), length=13, data=b"") Weirdest thing is probably a 65KB user+password setting... |
Interesting, will try to make a test case with this. |
I'll try and repro locally too. |
I have gdb working now so I can offer more details about the stack trace if necessary.
|
Is this on the current |
No, it wouldn't be. If it's fixed it's likely to roll through to OSSFuzz in the next day or so. |
@icing I've verified this still fails on latest master. |
@cmeister2 thanks for testing. Hmm, looking at |
@icing if it helps I can write down step by step repro instructions |
- refs curl#11500 - not clear how this triggers and it blocks OSSFuzz testing other things. Since we handle the case with an error return, disabling the assertion for now seems the best way forward.
In case this triggers something - with FUZZ_VERBOSE on:
|
- not clear how this triggers and it blocks OSSFuzz testing other things. Since we handle the case with an error return, disabling the assertion for now seems the best way forward. Fixes curl#11500 Closes curl#11519
I did this
OSS-Fuzz triggered this assert when fuzzing HTTP. It happens on http.c:2080.
Here's a stack trace
The text was updated successfully, but these errors were encountered: