fuzz: set flow flags as in Suricata

Fixes: d8ddef4c1485 ("detect: delay tx cleanup in some edge case")
(cherry picked from commit 09aed7e243127741721bd3e490c73d344234b17a)

github-ci: don't run builds on PR if only docs changed

(cherry picked from commit 3658d502fff9fb981d670aa79956a0f26e3cab2c)

github-ci: update Fedora non-root build to Fedora 41

(cherry picked from commit 65b863b087d8f6d7c0800700f89ca33f06ad861f)

github-ci: remove fedora 40 builds where 41 exists

Remove Fedora 40 builds where there is a Fedora 41 equivalent.

(cherry picked from commit 70d5bae160250457e040b138d9c399491561eb3a)

github-ci: update Fedora 39 jobs to 41

(cherry picked from commit c56b741088cd95c46ab5840588c4ef37bb2f89f3)

github-ci: bump known rust ver to 1.85.1

release: 7.0.10; update changelog

detect: add padding to suppress scan-build warning

Add to DetectEngineCtx to avoid:

./detect.h:840:16: warning: Excessive padding in 'struct DetectEngineCtx_' (32 padding bytes, where 0 is optimal). Optimal fields order: sig_list, srepCIDR_ctx, sig_array, sc_sig_order_funcs, sgh_hash_table, mpm_hash_table, pattern_hash_table, dup_sig_hash_table, spm_global_thread_ctx, mpm_ctx_factory_container, sgh_array, decoder_event_sgh, rule_file, sigerror, keyword_hash, next, dport_hash_table, tcp_whitelist, udp_whitelist, address_table, metadata_table, buffer_type_hash_name, buffer_type_hash_id, app_mpms_list, app_inspect_engines, pkt_inspect_engines, pkt_mpms_list, frame_inspect_engines, frame_mpms_list, prefilter_hash_table, fp_support_smlist_list, class_conf_ht, class_conf_regex, class_conf_regex_match, reference_conf_ht, reference_conf_regex, reference_conf_regex_match, ea, tenant_path, requirements, last_reload, sig_stat, ths_ctx, io_ctx, flow_gh, tenant_id, sig_cnt, srep_version, sig_array_size, sig_array_len, signum, non_pf_store_cnt_max, inspection_recursion_limit, filemagic_thread_ctx_id, max_fb_id, sgh_array_cnt, sgh_array_size, sgh_mpm_context_proto_tcp_packet, sgh_mpm_context_proto_udp_packet, sgh_mpm_context_proto_other_packet, sgh_mpm_context_stream, byte_extract_max_local_id, version, rule_line, keyword_id, type, ref_cnt, loader_id, prefilter_setting, buffer_type_id, app_mpms_list_cnt, pkt_mpms_list_cnt, frame_mpms_list_cnt, prefilter_id, filedata_config, max_uniq_toclient_groups, max_uniq_toserver_groups, base64_decode_max_len, filestore_cnt, failure_fatal, flags, mpm_matcher, spm_matcher, guess_applayer, sigerror_silent, sigerror_ok, sigerror_requires, filedata_config_initialized, sgh_mpm_ctx_cnf, config_prefix, sm_types_prefilter, sm_types_silent_error, consider reordering the fields or adding explicit padding members [optin.performance.Padding]
  840 | typedef struct DetectEngineCtx_ {
      |         ~~~~~~~^~~~~~~~~~~~~~~~~~
  841 |     bool failure_fatal;
      |     ~~~~~~~~~~~~~~~~~~~
  842 |     uint8_t flags;       /**< only DE_QUIET */
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  843 |     uint8_t mpm_matcher; /**< mpm matcher this ctx uses */
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  844 |     uint8_t spm_matcher; /**< spm matcher this ctx uses */
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  845 |
  846 |     uint32_t tenant_id;
      |     ~~~~~~~~~~~~~~~~~~~
  847 |
  848 |     Signature *sig_list;
      |     ~~~~~~~~~~~~~~~~~~~~
  849 |     uint32_t sig_cnt;
      |     ~~~~~~~~~~~~~~~~~
  850 |
  851 |     /* version of the srep data */
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  852 |     uint32_t srep_version;
      |     ~~~~~~~~~~~~~~~~~~~~~~
  853 |
  854 |     /* reputation for netblocks */
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  855 |     SRepCIDRTree *srepCIDR_ctx;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

af-packet: use actual snaplen in bpf

Avoids setting a 0 snaplen in BPF, leading to an error.

Fixes: b8b6ed550a6f ("af-packet: delay setting default-packet-size for af-packet")
Ticket: #7618.
(cherry picked from commit 749ffbd06a9034bfa0dec2ea6899d9cb9f8833f9)

datasets: work around scan-build warning

datasets.c:493:27: warning: Dereference of null pointer [core.NullDereference]
  493 |     DEBUG_VALIDATE_BUG_ON(set->hash->config.hash_size != hashsize);
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./util-validate.h:95:44: note: expanded from macro 'DEBUG_VALIDATE_BUG_ON'
   95 | #define DEBUG_VALIDATE_BUG_ON(exp) BUG_ON((exp))
      |                                            ^~~
./suricata-common.h:307:36: note: expanded from macro 'BUG_ON'
  307 |         #define BUG_ON(x) assert(!(x))
      |                                    ^
/usr/include/assert.h:109:7: note: expanded from macro 'assert'
  109 |     ((expr)                                                             \
      |       ^~~~
1 warning generated.

(cherry picked from commit c6fdf99cec1ba7067b20e68ea4e812cb4c043881)

version: start development towards 7.0.10

release: 7.0.9; update changelog

upgrade: list inspection recursion default limit

As the yaml indicated before that if no value was specified there were
no limits, and now there will be one.

(cherry picked from commit 3985b24e1b985653e9abd6367bdf621616abc85f)

datasets: set higher hashsize limits

To avoid possible upgrade issues, allow higher defaults than in the
master branch. Add some upgrade guidance and a note that defaults will
probably be further reduced.

detect: add configurable limits for datasets

Ticket: 7615

Avoids signatures setting extreme hash sizes, which would lead to very
high memory use.

Default to allowing:
- 65536 per dataset
- 16777216 total

To override these built-in defaults:

```yaml
datasets:
  # Limits for per rule dataset instances to avoid rules using too many
  # resources.
  limits:
    # Max value for per dataset `hashsize` setting
    #single-hashsize: 65536
    # Max combined hashsize values for all datasets.
    #total-hashsizes: 16777216
```

(cherry picked from commit a7713db709b8a0be5fc5e5809ab58e9b14a16e85)

datasets: improve default hashsize handling

Make hashsize default local to dataset code, instead of relying on the
thash code.

Use the same default value as before.

(cherry picked from commit d32a39ca4b53d7f659f4f0a2a5c162ef97dc4797)

doc/userguide: af-packet upgrade notes

Add note about increased block size and how to change it back to old
defaults if needed.

Ticket: #7458
(cherry picked from commit c6d18fc871ed5466f519a4109d81ca193c92fc7e)

af-packet: delay setting default-packet-size for af-packet

AF_PACKET needs more information about its configuration before we can
set the default packet size, so on startup, leave unset in suricata.c
if in AF_PACKET mode.

If defrag is enabled, use a default packet size of 9k for tpacket-v2.
This can still lead to truncation events, then the user can increase
their 'default-packet-size'.

Tpacket-v3 does not need an increased packet size as it will handle
any size of packet that is smaller than the configured block size
which now has a default of 128k.

9k for the snap is somewhat arbitrary but is large enough for the
common 9000 jumbo frame plus some extra headers including tpacket
headers.

Ticket: #7458
(cherry picked from commit b8b6ed550a6f10150f5ecf154e7b60c6dc2f84fe)

af-packet: warn that tpacket-v3 is better for non-inline usage

Ticket: #7458
(cherry picked from commit 8c7ac89791db16893673e7e5dc1001f802b9a641)

af-packet: add event for packets truncated by af-packet

Ticket: #7458
(cherry picked from commit d78f2c9a4e2b59f44daeddff098915084493d08d)

af-packet: warn if v3 block size is not large enough for defrag

If using tpacket-v3 and defrag, warn if the block size is not large
enough for a fully defragmented packet.

Ticket: #7458
(cherry picked from commit 9f96975d556bbff999482d83c331b96566461cd1)

af-packet: warn if v2 block size not large enough for defrag

If using tpacket-v2, defrag and a user provided v2-block-size, warn if
the block size is not large enough to hold one fully defragmented
packet.

Ticket: #7458
(cherry picked from commit 320ef7b61721a8d32d52c40fcc09592f0907bde6)

af-packet: make tpacket-v2 block size configurable

With the change of the default tpacket-v2 block size from 32k to 128k,
allow it to be configurable for users who may want to make it larger,
or revert it back to the pre 7.0.9 default of 32k.

Ticket: #7458
(cherry picked from commit 5871c6458c6696516425f19e8c840663767bf917)

af-packet: increase default block size

Increase the default block size from 32k to 128k. This allows for a
fully defragmented packet to fit in the buffer.

Ticket: #7458
(cherry picked from commit c342b054f40630521253666d3ca0192250a59ad2)

af-packet: warn if defrag not suitable for mode

AF_PACKET defrag should not be used for inline modes. Its possible that
a packet received could be larger than can be set when defrag is
enabled, so warn if disabled for inline use.

Likewise, warn if defrag is disabled for IDS use, or non-inline mode.

Ticket: #7458
(cherry picked from commit 808502d5cac0681e17859ed1aef9be8f508c4b13)

af-packet: check defrag value even if cluster-type not set

If cluster-type was not set we default to "cluster_flow" with defrag
always on. Instead check for defrag value and disable defrag if disabled
by the user.

Ticket: #7458
(cherry picked from commit 25d0fba91274e8d26e804f278c281a5c9f5309e9)

detect: limit base64_decode `bytes` to 64KiB

Ticket: 7613

Avoids potential large per-thread memory allocation. A buffer with the
size of the largest decode_base64 buffer size setting would be allocated
per thread. As this was a u32, it could mean a per-thread 4GiB memory
allocation.

64KiB was already the built-in default for cases where bytes size wasn't
specified.

(cherry picked from commit 32d0bd2bbb4d486623dec85a94952fde2515f2f0)

detect: non infinite default value for inspection-recursion-limit

So that empty config are protected by this setting as was intended.

Set to unlimited for fuzz testing.

(cherry picked from commit b9b797f1f4fcea02da5b051281e6f7d8d7786260)

detect/pcre: avoid infinite loop after negated pcre

Ticket: 7526

The usage of negated pcre, followed by other relative payload
content keywords could lead to an infinite loop.

This is because regular (not negated) pcre can test multiple
occurences, but negated pcre should be tried only once.

(cherry picked from commit b14c67cbdf25fa6c7ffe0d04ddf3ebe67b12b50b)

stream: RST no longer acks all data

Since forever (1578ef1e3e8a24d0cc615430c4e6bec1fefdad28) a valid RST
would update the internal `last_ack` representation to include all
unack'd data. This was originally done to make sure the unACK'd data was
inspected/processed at flow timeout.

It was observed however, that if GAPs existed in this unACK'd data, a
GAP could be reported in the stats and a GAP event would be raised. This
doesn't make sense, as missing segments in the unACK'd part of the
stream are completely normal. Segments simply do not all arrive in
order.

It turns out that the original behavior of updating `last_ack` to
include all unACK'd data is no longer needed.

For raw stream inspection, the detection engine will already include the
unACK'd data on flow end.

For app-layer updates the unACK'd data is often harmful, as the data
often has GAPs. Parser like the http parser would report these GAPs and
could also get confused about the post-GAP data being a new transaction
including a file. This lead to many reported errors and fantom txs and
files.

Since the GAP detection uses `last_ack` to determine GAPs, not moving
`last_ack` addresses the GAP false positives.

Ticket: #7422.
(cherry picked from commit bd1b9f62299422767056651f8f66d2bbd4e0bb14)

detect: delay tx cleanup in some edge case

Ticket: 7552

f->sgh_toserver may be NULL but because FLOW_SGH_TOSERVER is unset
and thus, we want to delay cleanup until detection has really been
run with the right signature group head.

This may happen for a rule using
`alert tcp any any -> any any` and
a app-layer keyword to client
with a app-layer supporting both udp and tcp
with stream.midstream=true
and with the first packet of a flow being a server response

In this case, we swap the flow and reset its signature group heads

(cherry picked from commit d8ddef4c1485004cfb24d0e4b1c490f185bedc92)

Additional fix in rfb unit test which moved to SV in suricata 8

detect: reset signature groups when reversing flow

Ticket: 7552

When we use midstream, and the first packet we see of a flow is
a response from server, and we want to match on some signature
to client :
- we had first set sgh_toserver/FLOW_SGH_TOSERVER as we first
  thought this was a packet to server
- we then swap/reverse the flow, so sgh_toclient becomes sgh_toserver
  but it contains signatures to server and cannot match our
  to_client signature

The detect engine with DetectRunSetup will set again the
signatures group heads properly

(cherry picked from commit d74bc774b75bcca613e5f48d907a425c3b46056a)

files: append data on closing even with FILE_NOSTORE

Ticket: 7577

When HTTP1 post multipart handles a small file, it will call
HTPFileClose with some data
This data needs to be appended to the streaming buffer for usage
by file.data keyword even if we do not end up storing the file

(cherry picked from commit f68e2f5537c95388858129aa1b076e976354584a)

app-layer: track modified/processed txs

To optimize detection, and logging, to avoid going through
all the live transactions when only a few were modified.

Two boolean fields are added to the tx data: updated_tc and ts
The app-layer parsers are now responsible to set these when
needed, and the logging and detection uses them to skip
transactions that were not updated.

There may some more optimization remaining by when we set
both updated_tc and updated_ts in functions returning
a mutable transaction, by checking if all the callers
are called in one direction only (request or response)

Ticket: 7087
(cherry picked from commit b02557ac7dd6b55187309cee93f849ee2917d0cb)

quic: discard late retry packets

Ticket: 7556

See RFC 9000 section 17.2.5.2 :
After the client has received and processed an Initial
or Retry packet from the server,
it MUST discard any subsequent Retry packets that it receives.

(cherry picked from commit 726de5520f77e778cd2511bf262611079ae2528d)

quic: decrypt only initial packets

Ticket: 7556

Avoids failed_decrypt events when the first packet seen is not
a Quic Initial packet

(cherry picked from commit d61f36c66fa6bb32d135e3891804081e16719cb4)

quic: handle retry packets

Ticket: 7556
(cherry picked from commit 6d8910d2455adcfd92c5970a3654d0bf90546489)

quic: handle fragmented hello over multiple packets

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

(cherry picked from commit f295cc059d0fb9666ff48b5156235f1aa611d010)

quic: parse ack frame number 3

cf rfc9000 section 19.3. ACK Frames

Ticket: 7556
(cherry picked from commit 68adc87bd20f0b09a95871ead88a558f4c94e788)

quic: move all_consuming check to callee

Will alow to have decode_frames accept one additional parameter
with past fragment data

(cherry picked from commit ee04d667b506ba6ab7f172c0e129e7b7cf617187)

rust: fixes for new clippy warnings

Fixes provided by cargo clippy --fix.

detect/krb5: avoid integer underflow with krb5.ticket_encryption

Ticket: 7560

When passing INT32_MIN aka 0x80000000, we cannot compute -vali
as it does not fit into a i32

(cherry picked from commit 8ae5665767a1660cdb0eaa8134c5910852b1afad)

dns: refactor tests to avoid assert!(false)

Mostly just unwrap instead of match as unwrap provides good
context. And replace a few assert!(false) with a descriptive panic.

rust: allow clippy::unused_unit for tests that use the test macro

The cause of the issue comes from the macro, which is provided by a
crate. Bust just to allow this for now.

dns: fix clippy lint warnings

Fix vector lint issues:
- same_item_push
- vec_init_then_push

(cherry picked from commit 2c0d3b83c442fc751f8418f3f4833d86cdd495d3)

rust: fix assertions_on_constants for assert!(true)

Which will be optimized away by the compiler

(cherry picked from commit c49463c86f4c54f3bd322eaead07ce9a2c0b1d56)

rust: fix single_binding

error: this match could be written as a `let` statement
   --> src/nfs/nfs3_records.rs:747:9
    |
747 | /         match result {
748 | |             (r, request) => {
749 | |                 assert_eq!(r.len(), 0);
750 | |                 assert_eq!(request.handle, expected_handle);
751 | |                 assert_eq!(request.name_vec, br#"bln"#);
752 | |             }
753 | |         }
    | |_________^

(cherry picked from commit 259cdf169e20b580643117b8fa227e470a0377f8)

rust: fix assertions_on_constants for assert!(false)

using panic! instead with a string message

(cherry picked from commit a8199bf2ca16e8394b6bf5c41ba1bafe88f6ff53)

rust: allow vec_init_then_push in tests

To supress the clippy lint in tests.

mqtt: always use 0x notation for hex in tests

Fixes clippy lint for zero_prefixed_literal.

tls: more permissive empty data eof check

If not all data is ACK'd during the FIN session shutdown, the last calls
to the parser can be with a non-NULL data pointer, but a input length of
0. This wasn't considered by the EOF check, which then lead to it being
seen as an error. No event was raised, but the tls error stats were
incremented.

Bug: #7554.
(cherry picked from commit 471bde442680cd22f4ca9493da7a824dfb8f8197)

github-ci: update actions/cache (deprecated)

It appears dependabot is a little behind on updating actions/cache.

doc/csum: Stream checksum validation change

Describe the change of behavior between the stream.checksum-validation
setting and checksum-based rule keywords.

(cherry picked from commit cfbf8fda94771461844b0fc805af5476f92328ce)

detect/csum: rm interaction btw stream setting/csum

Issue: 7467

Stream checksum validation no longer has a side effect of setting
PKT_IGNORE_CHECKSUM and thus, no longer affects csum keyword checks.

(cherry picked from commit 758da982f087dce249012304de7d3077adf9bade)

sip/parser: enforce valid chars for sip version

The `is_version_char` function incorrectly allowed characters that are not
part of the valid SIP version "SIP/2.0".

For instance, 'HTTP/1.1' was mistakenly accepted as a valid SIP version,
although it's not.

This commit fixes the issue by updating the condition to strictly
check for the correct version string.

cherry-picked from commit 69f841c9981147f55ec9f76d44f7ac138e726304

sip/parser: accept valid chars

Accepts valid characters as defined in RFC3261.

cherry-picked from commit 7e993d5081c35d62eada429bad43430417267e5a

rust/sip: rustfmt sip module

cherry-picked from commit 8ff80cb84d0e42f0fec92128e629eb040959fbcb

protodetect: finish probing parser sooner

Ticket: 7495

We want to finish also if we tested all the expected protocols
in mask, or if we tested even more.

There can be one more protocol coming from pe0, which can be
the protocol already found in the other direction.

(cherry picked from commit b5094b00b62ada4d8825f3c45898fc4c5e9d5b1f)

flow/var: Release key storage

Issue: 7466

This commit releases the memory for the flow variable "key" when
the flow variable is of type string. The key is allocated in the Lua
extension logic.

(cherry picked from commit 2d9df5a1aea4407846ce7e7e2fac58f65eb19073)

log/file: Ensure file ctx pointer is returned .

The fix for issue 7447 introduced an error with threaded eve output.

The changes that were committed for that issue mishandled the return
value when a file is being opened for the 2nd or higher time.

Instead of returning the existing file context, null was returned.

(cherry picked from commit 1d996c5aed820c34add5693a7a1bd4be00a1e304)

output/log: Remove extraneous error message

Issue: 7447

When the output file can't be opened, 2 error messages are displayed
for the same problem. The second message doesn't add value and lacks
context (error reason, e.g., "Permission denied").

Retaining the second message as a debug message.

Without this commit:

Error: logopenfile: Error opening file: "/home/jlucovsky/src/jal/suricata-verify/tests/bug-5198/output/noperms/eve.1.json": Permission denied [SCLogOpenFileFp:util-logopenfile.c:428]
Error: logopenfile: Unable to open slot 1 for file /home/jlucovsky/src/jal/suricata-verify/tests/bug-5198/output/noperms/eve.json [LogFileEnsureExists:util-logopenfile.c:737]
Error: runmodes: unable to initialize sub-module eve-log.stats [RunModeInitializeEveOutput:runmodes.c:692]

With commit:

Error: logopenfile: Error opening file: "/home/jlucovsky/src/jal/suricata-verify/tests/bug-5198/output/noperms/eve.1.json": Permission denied [SCLogOpenFileFp:util-logopenfile.c:428]
Error: runmodes: unable to initialize sub-module eve-log.stats [RunModeInitializeEveOutput:runmodes.c:692]
(cherry picked from commit d853972c744c789abbb61fa8e2fb567f4f6456ec)

output/log: Improve error handling

This commit improves error handling for cases when file(s) cannot be
opened.
- Return NULL if file object can't be opened
- checks whether the file object has been opened before
  dereferencing the per-file context.

Issue: 7447
(cherry picked from commit e72fc39f831e5c03d7884caa447eb758a345d1c8)

output/json: check 5-tuple values prior to logging

This commit enhances the JSON output by introducing a feature for conditional port logging.
Now, port logging is dependent on the underlying protocol
(such as TCP, UDP, or SCTP), where port information is pertinent, while it
avoids unnecessary logging for protocols where a port is not utilized (e.g. ARP).

Furthermore, this update ensures that IP addresses and the protocol have
meaningful values set, rather than being logged as empty strings.

These changes will make each log entry more precise, eliminating cases where
5-tuple fields are empty or set to zero, indicating the absence of a field.

Backported to address ticket: https://redmine.openinfosecfoundation.org/issues/7460

Ticket: #7460

(cherry picked from commit a1c6328156ffa1e3d690fa180b0395f9dcd9f52e)

flow/manager: fix multi instance row tracking

In multi instance flow manager setups, each flow manager gets a slice
of the hash table to manage. Due to a logic error in the chunked
scanning of the hash slice, instances beyond the first would always
rescan the same (first) subslice of their slice.

The `pos` variable that is used to keep the state of what the starting
position for the next scan was supposed to be, was treated as if it held
a relative value. Relative to the bounds of the slice. It was however,
holding an absolute position. This meant that when doing it's bounds
check it was always considered out of bounds. This would reset the sub-
slice to be scanned to the first part of the instances slice.

This patch addresses the issue by correctly handling the fact that the
value is absolute.

Bug: #7365.

Fixes: e9d2417e0ff3 ("flow/manager: adaptive hash eviction timing")
(cherry picked from commit ae072d5c07e0f5e02a8583127c7b3edd97f93d54)

flow/manager: add fn docs

(cherry picked from commit f97b4ec1e80cbf1fb18c6ca34dddbf1b43b03cbb)

stream: apply clang formatting

version: start development towards 7.0.9

release: 7.0.8; update changelog

stream: mark urgent experimental; set safe defaults

Uncomment in default config. This will make the policy "inline",
which is the same behavior as prior to the urgent policy support.

Add line to docs that this is an experimental feature.

doc/userguide: document TCP urgent policy

(cherry picked from commit d11e8a8ee7fb2cb2da0567de16bde344e1313f36)

eve/flow: add per flow TCP oob urg data counter

If TCP urgent handling is set to the OOB processing, the number of OOB
bytes is tracked for SEQ offset calculations. If this offset is
non-zero, add the field to the flow record.

Ticket: #7411.
(cherry picked from commit 779f9d8ba35c3f9b5abfa327d3a4209861bd2eb8)

stream: add TCP urgent handling options

TCP urgent handling is a complex topic due to conflicting RFCs and
implementations.

Until now the URG flag and urgent pointer values were simply ignored,
leading to an effective "inline" processing of urgent data. Many
implementations however, do not default to this behavior.

Many actual implementations use the urgent mechanism to send 1 byte of
data out of band to the application.

Complicating the matter is that the way the urgent logic is handled is
generally configurable both of the OS and the app level. So from the
network it is impossible to know with confidence what the settings are.

This patch adds the following policies:

`stream.reassembly.urgent.policy`:

- drop: drop URG packets before they affect the stream engine

- inline: ignore the urgent pointer and process all data inline

- oob (out of band): treat the last byte as out of band

- gap: skip the last byte, but do no adjust sequence offsets, leading to
       gaps in the data

For the `oob` option, tracking of a sequence number offset is required,
as the OOB data does "consume" sequence number space. This is limited to
64k. For this reason, there is a second policy:

`stream.reassembly.urgent.oob-limit-policy`:

- drop: drop URG packets before they affect the stream engine

- inline: ignore the urgent pointer and process all data inline

- gap: skip the last byte, but do no adjust sequence offsets, leading to
       gaps in the data

Bug: #7411.
(cherry picked from commit 6882bcb3e51bd3cf509fb6569cc30f48d7bb53d7)

stream: remove unused function argument

Sequence number is taken from seg, not the func arg.

(cherry picked from commit 4c1554f4f690a7e89c4190b0fa3f31a19d0bbedc)

decode/tcp: count urg flag

(cherry picked from commit ac02a71479c06d06a92683274987f7f898fb2c1c)

dns: provide events for recoverable parse errors

Add events for the following resource name parsing issues:

- name truncated as its too long
- maximum number of labels reached
- infinite loop

Currently these events are only registered when encountered, but
recoverable. That is where we are able to return some of the name,
usually in a truncated state.

As name parsing has many code paths, we pass in a pointer to a flag
field that can be updated by the name parser, this is done in
addition to the flags being set on a specific name as when logging we
want to designate which fields are truncated, etc. But for alerts, we
just care that something happened during the parse. It also reduces
errors as it won't be forgotten to check for the flags and set the
event if some new parser is written that also parses names.

Ticket: #7280

(cherry picked from commit 19cf0f81335d9f787d587450f7105ad95a648951)

eve/dns: add truncation flags for fields that are truncated

If rrname, rdata or mname are truncated, set a flag field like
'rrname_truncated: true' to indicate that the name is truncated.

Ticket: #7280

(cherry picked from commit 37f4c52b22fcdde4adf9b479cb5700f89d00768d)

dns: truncate names larger than 1025 characters

Once a name has gone over 1025 chars it will be truncated to 1025
chars and no more labels will be added to it, however the name will
continue to be parsed up to the label limit in attempt to find the end
so parsing can continue.

This introduces a new struct, DNSName which contains the name and any
flags which indicate any name parsing errors which should not error
out parsing the complete message, for example, infinite recursion
after some labels are parsed can continue, or truncation of name where
compression was used so we know the start of the next data to be
parsed.

This limits the logged DNS messages from being over our maximum size
of 10Mb in the case of really long names.

Ticket: #7280

(cherry picked from commit 3a5671739f5b25e5dd973a74ca5fd8ea40e1ae2d)

util/streaming-buffer: add extra safety check

Ticket: 7393

Check if GrowRegionToSize is called with an argument
trying to shrink the region size, and if so do nothing,
ie do not try to shrink, and just return ok.

This way, we avoid a buffer overflow from memeset using an
unsigned having underflowed.

(cherry picked from commit 9a53ec43b13f0039a083950511a18bf6f408e432)

util/streaming-buffer: check need to grow region

Ticket: 7393

As it was possible before earlier patches to get here
with mem_size lesser than start->buf_size,
which caused then an unsigned underflow and a buffer overflow.

(cherry picked from commit 8900041405dbb5f9584edae994af2100733fb4be)

util/streaming-buffer: fix regions intersection

This was not a problem for current callers in Suricata,
as RegionsIntersect is only called through StreamingBufferInsertAt
which is only used by TCP...

And TCP uses default region gap = 256kb, and only calls
StreamingBufferInsertAt with a u16, so TCP never inserts a new
data that will strictly contain an existing region augmented
with region gap, which was the only case where RegionsIntersect
returned the wrong result, which could later lead to a
buffer overflow.

Ticket: 7393
(cherry picked from commit 282509f70c4ce805098e59535af445362e3e9ebd)

doc: improve documentation about guess-applayer-tx

Ticket: 7199

detect: re-add app-layer to alerts on stream matches

The `guess-applayer-tx` work also removed the stream match condition
for adding app-layer metadata to alerts. This is a behavior change that
is not desired at this point, so this commit reverts that part of the
changes.

We keep the exising logging of app-layer metadata if the match was in
the stream.

detect: log app-layer metadata in alert with single tx

Ticket: 7199

Uses a config parameter detect.guess-applayer-tx to enable
this behavior (off by default)

This feature is requested for use cases with signatures not
using app-layer keywords but still targetting application
layer transactions, such as pass/drop rule combination,
or lua usage.

This overrides the previous behavior of checking if the signature
has a content match, by checking if there is only one live
transaction, in addition to the config parameter being set.

(cherry picked from commit f2c37763149f16da17326cb313750052e5a2117d)

detect: don't run pkt sigs on ffr pkts

Last packet from the TLS TCP session moves TCP state to CLOSED.

This flags the app-layer with APP_LAYER_PARSER_EOF_TS or
APP_LAYER_PARSER_EOF_TC depending on the direction of the final packet.
This flag will just have been set in a single direction.

This leads to the last packet updating the inspect id in that packets
direction.

At the end of the TLS session a pseudo packet is created, because:
 - flow has ended
 - inspected tx id == 0, for at least one direction
 - total txs is 1

Then a packet rule matches:

```
alert tcp any any -> any 443 (flow: to_server;                  \
        flowbits:isset,tls_error;                               \
        sid:09901033; rev:1;                                    \
        msg:"Allow TLS error handling (outgoing packet)"; )
```

The `SIG_MASK_REQUIRE_REAL_PKT` is not preventing the match, as the
`flowbits` keyword doesn't set it.

To avoid this match. This patch skips signatures of the `SIG_TYPE_PKT`
for flow end packets.

Ticket: #7318.
(cherry picked from commit 0e4faba79ae7e9fbe36815956cfd44af6d7f9378)

dpdk: set ice PMD RSS key length to 52 bytes for all DPDK versions

ICE driver (Intel E810 NIC) requires/supports 52-byte long RSS key.
The 52 byte key length was mandatory from DPDK 23.11 when Suricata
was starting with independently configured ice PMD.

However, Suricata failed to start when ice PMD was part of
net_bonding PMD, requiring 52 byte RSS key even in DPDK versions
lower than 23.11. Since the support for the longer key is present
since DPDK 19.11 the key is set to 52 bytes for all versions.

Ticket: 7445
(cherry picked from commit 18ab9a6ccd2392f7e94db9623bb3383731038937)

detect/flowing: apply clang format changes

Related to
Task #7426

flowint: add isnotset support

Similar keywords use `isnotset`, while `flowint` only accepted `notset`
Opted to change the code, not only the regex, to keep the underlying
code also following the same patterns.

Task #7426

(cherry picked from commit 6e4a501e7c96a705df084fd1e74668bc70a00b89)

eve/alert: enrich decoder event

Default decoder event alert was very sparse, not even logging packet
type and pcap_cnt. Expand support for this record type. It will be more
useful with the ethernet headers and packet field, but these are still
disabled by default.

Ticket: #7433.
(cherry picked from commit 2fe2cf855310678141896195e3191fa582752e6c)

detect: fix decoder only events

Add missing setup part of the decoder event sgh.

Bug: #7414.
(cherry picked from commit b23fa51e331141a2743ef7ded4ec01db951ec697)

requires: add option to ignore unknown requirements

The new behavior in 8, and backported is to treat unknown requirements
as unsatisfied requirements.

For 7.0.8, add a configuration option, "ignore-unknown-requirements"
to completely ignore unknown requirements, effectively treating them
as available.

Ticket: #7434

requires: treat unknown requires keywords as unmet requirements

For example, "requires: foo bar" is an unknown requirement, however
its not tracked, nor an error as it follows the syntax. Instead,
record these unknown keywords, and fail the requirements check if any
are present.

A future version of Suricata may have new requires keywords, for
example a check for keywords.

Ticket: #7418
(cherry picked from commit 820a3e51b752867da1322f29d542e5844bb6e727)

rust: remove unnecessary lifetimes

Fix provided by cargo clipy --fix.

Backport of 7bdbe7ed32d220abae62c0fc6ed8fcbeba886454.

rust/smb: fix rustdoc line

'///' style rust comments/documentation come before the item being
documented.

Spotted by clippy.

(cherry picked from commit aa6e94fc73be4843e4379d3539ba4fee38b63aaf)

rust: allow static_mut_refs for now

But we should fix all these soon.

(cherry picked from commit 4c12165816681e97959be3e1e1cf28c6195a84da)

rust: update num-derive to 0.4.2

Includes Cargo.lock.in generated for just this single crate update
(minimal atomic update to keep Cargo.lock in sync with Cargo.toml).

This prevents the clippy warning:

    508 | #[derive(FromPrimitive, Debug)]
        |          ^------------
        |          |
        |          `FromPrimitive` is not local
        |          move the `impl` block outside of this constant `_IMPL_NUM_FromPrimitive_FOR_IsakmpPayloadType`
    509 | pub enum IsakmpPayloadType {
        |          ----------------- `IsakmpPayloadType` is not local
        |
        = note: the derive macro `FromPrimitive` defines the non-local `impl`, and may need to be changed
        = note: the derive macro `FromPrimitive` may come from an old version of the `num_derive` crate, try updating your dependency with `cargo update -p num_derive`
        = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
        = note: items in an anonymous const item (`const _: () = { ... }`) are treated as in the same scope as the anonymous const's declaration for the purpose of this lint
        = note: this warning originates in the derive macro `FromPrimitive` (in Nightly builds, run with -Z macro-backtrace for more info)

Backport of 8e408d37306e03d28888aa390e91fae09b28f392.

rust: sync Cargo.lock with Cargo.toml

This just updates some internal dependencies to our own crates in the
work-space.

util-buffer: expand by multiples of 4k

(cherry picked from commit 287d8360e7a7263e23194470ed59e08982f76e31)

output-json: drop eve records that are too long

In the situation where the mem buffer cannot be expanded to the
requested size, drop the log message.

For each JSON log context, a warning will be emitted once with a partial
bit of the log record being dropped to identify what event types may be
leading to large log records.

This also fixes the call to MemBufferExpand which is supposed be
passed the amount to expand by, not the new size required.

Ticket: #7300
(cherry picked from commit d39e42728a5b84d9cefbd4329034064d71c4e268)

mqtt: look for a reason code in all messages

instead of stopping on the first message if it does not
have a reason code, like conn and conn_ack

Was fixed in master by big refactor 0a1062fad2ece8f900113c381147e8e8bdd1c009

mqtt: double-check detection directions

Backport of commit 5d8252117f3a6643be5867c6f1f19caa316fd76d.

Ticket: 7323