## Summary While checking the code of the https://gitlab.com/wireshark/wireshark/-/work_items/21147 which is not an issue at the end, I came on this, which is not a security issue but more a potential DoS issue due to missing else case. The ECH transcript reconstruction loop that iterates over the inner ClientHello's extensions has a missing else branch. When the decrypted inner CH contains an ech_outer_extensions extension (type 0xfd00) with a data length of zero: - The if branch (line 10088) does not fire — the extension type is ECH_OUTER_EXTENSIONS. - The else if branch (line 10093) does not fire — the data length is not > 0. - Neither branch advances ech_offset, so the loop condition extensions_end - ech_offset >= 4 remains true forever. Wireshark/tshark enters an infinite loop at 100% CPU. ## AI assistance None ## Sample capture file [ech_infinite_loop.keys](/uploads/60924da1bc07acbab5a3c583d88729ae/ech_infinite_loop.keys) [ech_infinite_loop.pcap](/uploads/15b333a9760e0e2a5344e0214f480cee/ech_infinite_loop.pcap) ## Steps to reproduce tshark -o tls.keylog_file:ech_infinite_loop.keys -r ech_infinite_loop.pcap This is obviously only realistic when the attacker provides both a pcap and the keylog file or might be in other case not sure. ## What is the current bug behavior? Wireshark/tshark enters an infinite loop at 100% CPU. ## What is the expected correct behavior? (What you should see instead) ## Build information commit b9b241d185683d04b385eca0b94d449e200b558a ``` TShark (Wireshark) 4.7.0 Compile-time info: Bit width: 64-bit Compiler: GCC 13.3.0 GLib: 2.80.0 With: +Gcrypt 1.10.3 +libxml2 2.9.14 +zlib 1.3 +libpcap +PCRE2 10.42 2022-12-11 Without: -brotli -Lua -POSIX capabilities -GnuTLS -LZ4 -Snappy -Kerberos -MaxMind -xxhash -libnl -nghttp2 -zlib-ng -libsmi -nghttp3 -Zstandard Runtime info: OS: Linux 6.12.76-linuxkit CPU: Memory: 7835 MB of physical memory GLib: 2.80.0 Locale: LC_TYPE=C Plugins: supported, 0 loaded With: +c-ares 1.27.0 +PCRE2 10.42 2022-12-11 +Gcrypt 1.10.3 +zlib 1.3 +libpcap 1.10.4 (with TPACKET_V3) ```