Quic crypto reassembly 7556 v3 #12597
Conversation
Will alow to have decode_frames accept one additional parameter with past fragment data
Ticket: 7556 To do so, we need to add 2 buffers (one for each direction) to the QuicState structure, so that on parsing the second packet with hello/crypto fragment, we still have the data of the first hello/crypto fragment. Use a hardcoded limit so that these buffers cannot grow indefinitely and set an event when reaching the limit
cf rfc9000 section 19.3. ACK Frames Ticket: 7556
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12597 +/- ##
==========================================
+ Coverage 80.73% 80.74% +0.01%
==========================================
Files 931 931
Lines 259136 259198 +62
==========================================
+ Hits 209215 209300 +85
+ Misses 49921 49898 -23
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
This seems to be a lot cleaner on my network. Still seeing some issues, this time a session with a fragmented server hello, where frags are out of order. Pcap https://redmine.openinfosecfoundation.org/issues/7556?next_issue_id=7555&prev_issue_id=7557#note-9 |
|
Next in #12615 |
The issue was caused by packet 5 not bringing in a new crypto fragment (packet 4 brought a a first one) and so we ended up forgetting the data without having got it all... |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7556
Describe changes:
SV_BRANCH=OISF/suricata-verify#2296
#12593 with fix of bug found by cluster fuzz lite :
vec![0; crypto_max_size as usize];would have been arbitrary size allocation