Bug in LZ77 decoder; reads a 16-bit length when it should read a 32-bit length

Summary

The do_uncompress() function in epan/tvbuff_lz77.c misreads the "very big" length and should be fixed thusly:

--- a/epan/tvbuff_lz77.c
+++ b/epan/tvbuff_lz77.c
@@ -68,7 +68,7 @@ static bool do_uncompress(tvbuff_t *tvb, int offset, int in_size,
 						in_off += 2;
 						if (match_len == 0) {
 							/* This case isn't documented */
-							match_len = tvb_get_letohs(tvb, offset+in_off);
+							match_len = tvb_get_letohl(tvb, offset+in_off);
 							in_off += 4;
 						}
 						if (match_len < 15+7)

Steps to reproduce

Capture the writing of a 1MiB file to a share on a Windows SMB (CIFS) server that supports transport compression.

What is the current bug behavior?

The compressed SMB Write request is flagged as "Comp. SMB3 (invalid)" in the packet list in wireshark.

What is the expected correct behavior?

The compressed SMB Write request should be decompressed and the contained write should be visible and decoded.

Sample capture file

I've attached a sample file with just the frame of interest. lz77-bug.pcapng.gz

Relevant logs and/or screenshots

(Paste any relevant logs)

Build information

I see this with Fedora 41 and also with manually built git commit fbab43c608cef1cd6092adce1b3d18db845b3843 on the wireshark master branch.[pcap-lz77.gz]```