-
Notifications
You must be signed in to change notification settings - Fork 762
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
QUIC: segfault in qcc_recv_stop_sending #2563
Comments
I don't know if it's expected, but I note some application-level data now can show up in backtraces (don't think it was ever the case before); specifically in thread 4 here:
Which can include PII/secrets if it prints out sensitive headers like Cookie and XFF/Forwarded in this case. Not that I personally mind that much (I'll just pay closer attention in the future), but I figure it was not by sheer luck that this never was the case in the past. |
nb: if it's being a big pain to figure out on your end, let me know, I can probably reasonably get traces in this case as it's really common |
Okay this part as changed recently. The fix should be easy enough here, no need for any traces thanks. |
Abort reason code received on STOP_SENDING is notified to upper layer since the following commit : 367ce1e MINOR: mux-quic: Set tha SE abort reason when a STOP_SENDING frame is received However, this causes a crash when a STOP_SENDING is received on a QCS instance without any stream instantiated. Fix this by checking first if qcs->sd is not NULL before setting abort code. This bug can easily be reproduced by emitting a STOP_SENDING as first frame of a stream. This should fix github issue #2563. This does not need to be backported.
Regarding the risk of data in traces, it solely depends on where the code crashes and what gdb will print. Typically if one of the functions in the stack has a pointer argument to such a string or buffer for example and gdb decodes it, it will indeed appear. I think that you should be able to truncate the length of such strings in backtraces using "set print elements 10" (it should limit it to 10 chars). 0 is unlimited. |
I guess so, but I was just surprised as I think it's the first time that happens so clearly in a HAProxy backtrace over the past years and however many backtraces I got :) So I was (wrongfully) thinking there was some logic preventing it (printing L7 data, that is) at play. I'll just keep an eye out for it in the future either way, it's fine 👍 |
Btw I can confirm that the crash is fixed 👍 |
Detailed Description of the Problem
HAProxy crashes
Expected Behavior
No crash
Steps to Reproduce the Behavior
Do you have any idea what may have caused this?
No response
Do you have an idea how to solve the issue?
No response
What is your configuration?
Output of
haproxy -vv
Last Outputs and Backtraces
Additional Information
No response
The text was updated successfully, but these errors were encountered: