Re: https://bugs.chromium.org/p/boringssl/issues/detail?id=558#c1
Since a recent change that puts boringssl's public API more in line with OpenSSL, there is a constness mismatch in the function type of `copy_X509` that may cause compilation failures.
As it turns out, the function we are using there (`sk_deep_copy`) is documented as a private API. We could use `sk_X509_deep_copy`, casting away the const in `copy_X509` to increment the refcount, but the existing function `X509_chain_up_ref` does exactly what we want here.
1) on_new_conn only be called after handshake_ok
2) on_conn_closed only be called by ietf_full_conn_ci_destroy
Co-authored-by: wangfuyu <ivanfywang@gmail.com>
* fix memory leak when gquic50 decrypt packet
fix a suspicious memory leak in gquic and iquic
* drop some redundant checking.
Co-authored-by: linsc <linsc@wangus.com>
RFC9000 3.5.
A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the "Ready" or "Send" state. If the stream is in the "Data Sent" state, the endpoint MAY defer sending the RESET_STREAM frame until the packets containing outstanding data are acknowledged or declared lost. If any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM frame instead of retransmitting the data.
RFC9000 19.4. RESET_Frames
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly terminate the sending part of a stream.
Co-authored-by: wangfuyu <wangfuyu@gmail.com>
[Reproduce]
http_client POST large body request to http_server, like:
http_client -H quic.test.com -s ${SERVER_ADDR}:${SERVER_PORT} -p /1KB_char.txt -M POST -P /test/quic-data/html/10KB_char.txt -o version=h3 -n 100 -r 50000000 -R 500 -w 10 -K
[Notes]
[RFC5116 AEAD] Section 5.1
An authentication tag with a length of 16 octets (128bits) is used.
[RFC9001 QUIC-TLS] Section 5.3
These cipher suites have a 16-byte authentication tag and
produce an output 16 bytes larger than their input.
Co-authored-by: wangfuyu <ivanfywang@gmail.com>
Description:
- Error may occur while processing ack frame, e.g. poison packet was
acked by hostile attack. and then conn is supposed to be aborted,
shortly but not immediately;
- if ack frame processing failed while calling lsquic_engine_packet_in,
and IFC_HAVE_SAVED_ACK had been set, then saved ack frame will be
processed while ticking connection before it is aborted, that may
lead to assert failure;
Solution:
- close connection if neccessary before processing ack while ci_tick.
1) After handshake done, handshake packets should not be sent or received.
2) IFC_ACK_QUED_HSK will be cancelled from conn->ifc_flags after handshake done, but it maybe set again if ACKs for handshake lost(Function: should_generate_ack).
Co-authored-by: ivanfywang <ivanfywang@gmail.com>
* Test case and debug for lsquic rechist list problem
Add:
- test case
- debug rechist print function (not called)
Modify:
- rechist_test_sanity to be more robust
Test case:
Added test case which produces a corrupt rechist. The rechist
grows and then is emptied, then a rechist is produced that is nominally
empty (rh_n_used == 0) but has a circular list in rh_elems. E.g. (using
debug print at the problem site):
lsquic_rechist_received: insert before done
0x7ffe65ce75a0: cutoff 9 l. acked 12087061905995 masks 1 alloced 4 used 1 max ranges 0 head 0
(0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9]
test_rechist: /tmp/lsquic/src/liblsquic/lsquic_rechist.c:272: rechist_test_sanity: Assertion `rechist->rh_n_used == n_elems' failed.
Debug print:
Added 'rechist_dump' for ease of debugging, marked as unused.
Useful for calling from gdb or adding to code temporarily.
rechist_test_sanity:
Make it more robust to bad rechists by limiting
how many list items it will follow, to prevent infinite loops or walking off
the end of the list.
* rechist: Fix bug in lsquic_rechist_received causing circular list to be created
Fix bug in lsquic_rechist_received demonstrated by the test6 test-case.
When the list is empty, i.e. rh_n_used == 0, the 'first_elem' path should
be used. However, the test for this was using rh_n_alloced, which would
cause the code to continue on incorrectly. One possibility is that it goes
to insert_before and creates a circular list in the rechist with the head at
index 0 having a next of 0.
This causes history to be lost I think.
The list at this point is still 'empty', however a following call could go
to the insert_before path and then insert an elem pointing to the circular
list, and bump up rh_n_used. Now you have a circular list.
Weird things can happen now. Notably, ACK generation will exhaust the
packet buffer and generate an error, and so cause connections to be
prematurely aborted.
Fix lsquic_rechist_received to use rh_n_used. Also modify
rechist_alloc_elem to NULL the next pointer for robustness.
It would be nice for rechist_free_elem to also invalidate the elem, but it
is meant for relinking elems in the list and should preserve the next
pointer.
