Bug #4549
closedTCP reassembly, failed assert app_progress > last_ack_abs, both sides need to be pruned
Description
Found by oss-fuzz
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35626
Minimized reproducer with suricata is./src/suricata -r lolb.pcap -k none -c suricata.yaml --set stream.midstream=true
What happens is
- first packet (midstream) all ok (ack = 1)
- second packet, from the other side, ack is ok, but sequence indicates a gap from first packet ack (seq = 77)
- third packet, sequence ok, ack is increased since first packet confirming the gap (ack = 77) StreamTcpUpdateAppLayerProgress
is called by AppLayerHandleTCPData
at the end of if (flags & STREAM_GAP) {
- Fourth packet is in first direction (seq and ack meaningless)
At the end of third packet, the 76 gap does not get subtracted in app_progress_rel
as StreamTcpPruneSession
only considers the other stream
Files
Updated by Philippe Antoine over 3 years ago
Side note : the fuzz target and suricata do not seem to handle the pcap timestamps the same way : Suricata does not crash on the original pcap because it did not time out a flow when the fuzz target did time it out (and so started a new one with the same flow hash)
Updated by Philippe Antoine over 3 years ago
Interesting reference : https://github.com/OISF/suricata/pull/5325/commits/b6fed6d431bb09b573555b2560eb805a59cd91ec
Updated by Jeff Lucovsky over 3 years ago
- Copied to Bug #4645: TCP reassembly, failed assert app_progress > last_ack_abs, both sides need to be pruned added
Updated by Jeff Lucovsky over 3 years ago
- Copied to Bug #4646: TCP reassembly, failed assert app_progress > last_ack_abs, both sides need to be pruned added
Updated by Philippe Antoine almost 3 years ago
Updated by Victor Julien over 2 years ago
- Status changed from In Review to Closed
- Assignee changed from Philippe Antoine to Victor Julien