Close the directory handle we've opened before returning a failure
indication if pbw_load_proto_file() or load_all_files_in_dir() reports a
failure.
(cherry picked from commit f0abd29e48)
Free the path we've constructed before returning a failure indication if
pbw_load_proto_file() or load_all_files_in_dir() reports a failure.
Also, explicitly compare pbw_load_proto_file()'s return value against 0,
to make it a little clearer that it's *not* a Boolean, it's a return
code (with 0 meaning success and different non-zero values meaning
failure; if it matters *which* failure it is, we should probably have
otherwise we should just make it a Boolean).
(cherry picked from commit f1ffe7d421)
0af60377b4 added an heuristic to detect (unencrypted) padding data;
it is based on the fact that all coalesced QUIC packets must have the
same CID.
Unfortunately it doesn't work when the CID length is 0.
Treat decryption error of SH packets as a non fatal error, report them
as possible padding data misdetectd as coalesced packets and try
decrypting next traffic.
Close#17383
(cherry picked from commit 389a899a18)
Make sure we have enough bytes for Length and Type fields before we read
from tvb.
Using existing msg_len for the checks.
Closes: wireshark/wireshark#17355
(cherry picked from commit fd14396972)
commit 19b3376a24
("LDAP bogus malformed errors: decoding encrypted data")
introduced 2 problems:
- guint decr_len = tvb_reported_length(decr_tvb); was
always called with decr_tvb==NULL
- dissect_ldap_payload() was not called if sasl_tree is NULL,
it needs to be called even if the tree pointer are NULL
in order to have the COL_INFO setup correctly.
I guess this should also be backported to stable branches
(together with 2e6d3b571b
"LDAP: SASL Buffer doesn't include Length field")
https://gitlab.com/wireshark/wireshark/-/issues/17347
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 1d623fd541)
SASL Buffer starts after the SASL Buffer Length field. Therefore
we should only mark the bytes without the Length field.
Sample capture can be found in wireshark/wireshark#15128
(cherry picked from commit 2e6d3b571b)
If the proto tree is more than 8 levels deep, the subtree_lvl array
length is extended, by allocating a new area and copying everything into
that new area. However the old array length wasn't calculated correctly,
so only part of the subtree_lvl array was copied, causing a crash after
two ptvcursor_pop_subtree() calls.
(cherry picked from commit fa483ac191)
- parse the number of system call arguments in a way that works for both V1 and V2 event blocks
- returned the correct error string when unable to read the nparams entry from a sysdig event block V2
(cherry picked from commit 7894b1d0ea)
Update the pcap-ng reader and sysdig event dissector to support the second version of the sysdig event block, which was introduced after Wireshark's original implementation
(cherry picked from commit fbe8d3a00f)
When tshark enables synchronous resolution of IP addresses to names,
forces calls to maxmind_db_lookup_ipv4()/_ipv6() to block-wait for the
maxmind response.
Proposed fix for #14691.
(backported from commit c0abaa06f7)
Both subset_find_guint8() and subset_pbrk_guint8() pass the parent
tvbuff to tvb_find_guint8()/tvb_ws_mempbrk_pattern_guint8(), along with
the offset in that tvbuff.
That means that the offset they get back is relative to that tvbuff, so
it must be adjusted to be relative to the tvbuff *they* were handed.
For subsets of frame and "real data" tvbuffs, there's a single lump of
data containing the content of the subset tvbuff, so they go through the
"fast path" and get the offset correct, bypassing the broken code;
that's the vast majority of calls to those routines.
For subsets of *composite* tvbuffs, however, they don't go through the
"fast path", and this bug shows up.
This causes both crashes and misdissection of HTTP if the link-layer is
PPP with Van Jacobson compression, as the decompression uses composite
tvbuffs.
Fixes#17254 and its many soon-to-be-duplicates.
(cherry picked from commit 2ba52cdc0e)
The length specified in a TvbRange is the *actual packet length*, not
the *sliced-to* length, so use tvb_new_subset_length() to cut it short.
This fixes the fix for #15655, and addresses at least some of the issues
in #17255.
(cherry picked from commit cda18f951e)
* Since c3342930 we don't free anymore the entries in the files hashtables.
The cleanest solution is probably to convert these hashtables into two
wmem_map_t structures and let the wmem core handling any cleanup.
* b0f5b2c174 added supported for chained compression; the uncompressed
tvb must be freed
(cherry picked from commit e677a909e1)
IXFR and AXFR queries can have multiple DNS responses. As all responses
belong to one transaction, they have the same transaction ID.
We shouldn't handle them as retransmits.
Fix: wireshark/wireshark#17293
(cherry picked from commit 07fb47111e)
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
(cherry picked from commit 2820156fbd)
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
(cherry picked from commit 1e1f4e6b5f)
This patch fixes a bug in the current TECMP dissector that leads to
wrong timestamps, whenever the reserved flag is set to true.
Closes: #17279
(cherry picked from commit 5d709459c4)
This commit should be a proper fix for the regression reported in #17250
(7fd71536 is a simple workaround). Such regression has been introduced by
b287e716 while fixing the infinite loop reported in #16897.
b287e716, while fixing the infinite loop, broke the decoding of perfectly
valid tags not yet supported by Wireshark.
AFAIK, the root cause of the infinite loop is the overflow of the `offset`
variable. Therefore checking for this overflow should be sufficient to avoid
the loop.
Note that we already check for sensible values for the 'tag_len' variable;
we should update `total_tag_len` accordingly.
Some words about testing: other than correctly handling unknown but valid
tags, it is important that this commit doesn't reintroduce the infinite
loop bug.
Fortunately #16897 provided a POC trace. Unfortunately, if you revert
b287e716, this POC doesn't work anymore in master-3.4 and master branches,
but it still triggers the infinite loop in master-3.2 branch.
Therefore I have been able to manually check that this MR + the
overflow check is enough to avoid the infinite loop bug, at least in master-3.2.
Some traffic with unknown but valid tags is available in e2ee14ae03.
(cherry picked from commit 142cfb03ac)
Regression introduced by b287e7165e.
To avoid an infinite loop with malformed packets, that commit stops
parsing the tags list after finding an unknown tag.
When this "unknown" tag is perfectly valid but not supported by
Wireshark, we don't decode any subsequent (valid) tags anymore.
GQUIC is going to die soon and it is quite unlikely it will change in
the next future. Therefore the best/quick solution is simply decoding
any valid tag.
Close#17250
(cherry picked from commit 7fd7153696)
These will be backported, for the benefit of Lua scripts that want those
specific file types/subtypes (typically in order to write files of those
types); that allows those types to be fetched without having to know the
right string to hand to wslua_wtap_name_to_file_type_subtype().
(cherry picked from commit bc3cc17bc4)
In the proto tree, copy URLs instead of opening them.
In the export dialog, enable previews only if the advertised MIME type
*and* the contents of the file are plain text, GIF, JPEG, or PNG.
Add warnings to the wslua browser_open_url and browser_open_data_file
documentation.
Fixes#17232.
(cherry picked from commit e99c9afce8)
Recommend the use of wtap_name_to_file_type_subtype() to get filetype
values, unless you need to run on older versions of Wireshark that don't
have it.
Don't even *mention* wtap_filetypes in the documentation for the new
wtap_ routines, as, if you have those routines, you have
wtap_name_to_file_type_subtype(), because it's one of those routines.
Fix references to "nul" while we're at it - it's "nil" in Lua.
(That part of the WSDG - the Lua reference - is generated, so this
involves changing the source code implementing the Lua routines.)
(cherry picked from commit 5b3c3d0682)
Provide Lua version of wtap_file_type_subtype_string(),
wtap_file_type_subtype_short_string(), and
wtap_short_string_to_file_type_subtype().
This will be backported to the 3.2 and 3.4 branches, to allow scripts
not run on the bleeding-edge version to use them.
(cherry picked from commit f0ebc50762)
In our first pass through our options, look for ones that might require
extcap. Call extcap_register_preferences() only when that's the case.
Warn about missing extcap preferences only when we've loaded them.
(cherry picked from commit c7f66cf934)
Conflicts:
tshark.c
Without this patch, any Linux cooked packet capture on HDLC / frame
relay devices will not be dispatched to the proper dissector.
Such packets do carry a proper sll_hatype set to ARPHRD_FRAD and should
be dispatched accordingly. However, the packet-fr dissector so far
did not register itself accordingly.
(cherry picked from commit b83f92a458)
When the refid contains non-ascii chars, the conversion function
returns a string longer than 4 chars. This results in an invalid
string if the output is limited to 4 bytes. Incidentally this
results in an invalid PDML output as well that caught this bug
in the first place.
Fix: #17112.
10204490d7 / MR 80 ensured that we didn't grow field.usages due to an
underflow, but it neglected to check for a sane array size. Add another
check to make sure we don't wmem_array_grow() too much. Fixes#17165 and
fixes#16809 more completely.
(cherry picked from commit 785e291c1b)
Usage Minimum and Usage Maximum are an inclusive, closed interval.
This fixes an fencepost error where the Usage Maximum value was
not being included as a possible value in the bitfield. Related
to #17014
(cherry picked from commit 5ca608f519)
Guy Harris
Harald Welte