On Wed, Feb 22, 2023 at 10:28:45AM +0100, Peter J. Philipp wrote: > On Mon, Feb 20, 2023 at 02:39:45PM +0100, p...@delphinusdns.org wrote: > > >Synopsis: possible underflow in tcpdump/print-gre.c > > >Category: user > > >Environment: > > System : OpenBSD 7.2 > > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022 > > > > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > > > Architecture: OpenBSD.arm64 > > Machine : arm64 > > >Description: > > In tcpdump/print-ether.c length is initialized as h->len (struct > > pcap_pkthdr). > > snapend is based on p + h->caplen (struct pcap_pkthdr), which is based > > on > > snaplen. > > > > In tcpdump/print-gre.c u_int l is derived from snapend - p (line 123) > > and great care is taken that l does not underflow to the u_int maximum. > > However length is not checked for underflow and it is possibly > > initially smaller than snapend - p (snaplen). It is then passed to > > other > > functions under line number 234. > > > > >How-To-Repeat: > > never tested in practice, code-reading only. > > >Fix: > > length should be checked for underflow. To do this save length at > > start of function and then test this whether length increased since it > > is u_int it will underflow into the high 2 billion region. > > > OK, I turned this around into practice. It's not possible with most protocols > but with GRE and NSH it is possible to segfault tcpdump if the -v options is > used (often much so the case, at least for me). Here is a paste from my > tcpdump:
This crash is no fixed. the Problem was a bad call to default_print_unaligned() in nsh_print(). The wrong length parameter was passed there. Also I added an extra check to default_print() to prevent this function to read past the end of the snap buffer. -- :wq Claudio
