Pull request #3228: stream_tcp: fix PDU buffer overflow on fallback

Merge in SNORT/snort3 from ~VHORBATO/snort3:def_reassm_overflow to master

Squashed commit of the following:

commit 97a97f3dc033732bb92b802a10bb20f71623c82c
Author: russ <rucombs@cisco.com>
Date:   Sun Dec 19 10:41:02 2021 -0500

    stream_tcp: limit reassembly size for AtomSplitter

    Thanks to barosch78 and DAKOIT for their help in the process of finding the root cause.

diff --git a/src/stream/stream_splitter.cc b/src/stream/stream_splitter.cc
index 721c66f9836ddbe94fd3900ca217757bc348bf54..df07b1c7dee2bb3363a28597f95f84de1785b05f 100644 (file)
--- a/src/stream/stream_splitter.cc
+++ b/src/stream/stream_splitter.cc
@@ -44,15 +44,27 @@ const StreamBuffer StreamSplitter::reassemble(
     Flow*, unsigned, unsigned offset, const uint8_t* p,
     unsigned n, uint32_t flags, unsigned& copied)
 {
-    copied = n;
     if (n == 0)
         return { nullptr, 0 };
 
     unsigned max;
     uint8_t* pdu_buf = DetectionEngine::get_next_buffer(max);
+    max = max > Packet::max_dsize ? Packet::max_dsize : max;
+
+    n = std::min(n, max - offset);
+    /*
+    FIXIT:
+        - Extra bytes will be lost and will pass without inspection
+        - There is some inconsistency between IpsContext::buf_size (Codec::PKT_MAX)
+            and Packet::max_dsize(IP_MAXPACKET)
+        - reassemble returns data length(StreamBuffer::length) of 32-bit type, while some
+            callers use 16-bit type for the length
+        - How it correlates with stream_tcp.max_pdu which has {1460:32768} range,
+            should it be adjusted with --snaplen {68:65535}?
+    */
 
-    assert(offset + n < max);
     memcpy(pdu_buf+offset, p, n);
+    copied = n;
 
     if ( flags & PKT_PDU_TAIL )
         return { pdu_buf, offset + n };