The check that meant to check if pcap_dispatch processed fewer packets
than the desired number was inaccurate. It would also include all errors
(negative return values).
This patch considers only positive values for this check.
Fixes: 9fe08f2374 ("pcap: improve pcap_breakloop support")
Before:
If LF character was found, so far, we won't enforce the line limit on
the line. We only enforced limits in case of LF character missing in a
long line.
After this patch:
Line limit is enforced on the line if it is bigger than 4096 Bytes
irrespective of whether LF was found or not.
Redmine Bug: 5819
Instead of tracking ip only rules by the internal signum, track them by
a separate counter that starts at zero. This results in dense
SigNumArrays instead of sparse ones and a much smaller max_idx.
Issue: 4578
When pcap_breakloop has been issued on a handle, the current pcap_dispatch
call may return -2 (PCAP_ERROR_BREAK), but it can also return the number
of processed packets if lower than the desired number. So add this condition
as a check.
During housekeeping multiple flows are processed. If a rule reload happens
at that time, we need to use the new detect thread as soon as possible.
Bug: #5969.
The logical error may have been made here. Comparison with the upper
bound of the variable type does not make sense. It may be worth adding
the cast of one of the multiplication operands to the 64-bit type for
avoiding overflow.
Found by Security Code with Svace static analyzer
Bug: #5789
Signed-off-by: Maxim Korotkov <m.korotkov@securitycode.ru>
After recent next_seq changes, the FIN checks could be too strict
leading to stalling sessions in IPS mode.
This patch requires a FIN to be >= last ack and <= next_win to be
accepted.
Old behavior:
With RFC4648, the decoded bytes were reset to 0 in case an unusual
character was encountered in the encoded string. This worked out fine
for small test cases where there weren't many bytes to be decoded.
Problem:
If a big encoded string had a character outside of the base alphabet,
the processing would stop and the number of decoded bytes were set to 0.
However, even though the processing should stop at the invalid
character, the number of decoded bytes should correctly store the bytes
decoded up until the point an invalid characted was encountered.
New behavor:
For any base64 encoded string given to the base64 decoder in RFC4648
mode, we make sure that the number of decoded bytes correctly reflect
the number of bytes processed up until the string was valid. This makes
sure any further calculations/use of the decoded data is done correctly.
Redmine ticket: 5885
Build on Eric's but set the direction on transaction creation when
needed. I think this makes it a little more clear, and easier to
document when creating single direction transactions.
This also somewhat abstracts the inner-workings of a directional
transaction from the implementation.
Ticket: #4759
By implementing the no inspection flag we can now set
the unidirectional TX flag. Which means that the alstate
progress function can now be simplified to always return
1 f the transaction is complete.
Ticket: #5799