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.
George Wang
Mickael Cerisier
wangfuyu
Hadi Frohar
Kent Ross
linsichen206
Pluto
davidleitw
M-BELLAHCENE
Paul Jakma
Ryan A. Pavlik