print-nfs prints beyond end of string

[guyharris]

Converted from SourceForge issue 592852, submitted by nobody

Version 3.7.1
Machine: i686
Os: Linux 2.2.16-22enterprise
Command: tcpdump -tuNl -s 200 port nfsd
Problem: segmentation faults
The last packet printed in a sample execution is:
silver.482673452 > marble.nfs: 124 lookup fh
Unknown/CABAEBFE85A6370002000000110800001108000002000000EAF25E5A00000000
"^@ssh^@^@^@M-_M-FM-zM-vM-^GM-'jM-zM-&M-%M-`^O^@M-hM-^WM-^/M-xM-^MM-p/NM-V4M-kO^@x^WM-a^@^@^Q^@^@^@PORT
nfsd^@^@^@^Y^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Y^@^@^@x^O^U^H^@^

... and a lot of more garbage, until it crashes.

The actual last packet printed actually varies from an
execution to
another, but the problem is always the same: when
printing some nfs
lookup request packets, the string printing loop goes
past the end of the string representing the filename,
until it hits a memory location out of the process image.

I had a look at the source code: I think the problem
happens in
fn_printn() called from parsefn() in print-nfs.c. I
changed the call
to
fn_printn(cp, len, snaplen);
and it does not segfault anymore, but all the printed
filenames in
lookup requests are empty.

Ruggero
ruggero@wam.umd.edu

[guyharris]

Submitted by guy_harris

Logged In: YES
user_id=541179

"fn_printn()" takes as its third argument a "const char *",
not an "int", so "snaplen" would be the wrong argument to
pass to it. (As you're using Linux, your compiler is
probably GCC, in which case you should create a ".devel"
file in your tcpdump source directory, and re-run the
configure script; that'll cause some additional warning
flags to be used, which should cause the compiler to print a
warning about incorrect calls such as that.)

However, there's a TCHECK2() call before the fn_printn()
call, so if not all the name was captured in the request,
the TCHECK2() call should fail (jumping to "trunc:") before
fn_printn() even gets called.

It might have tripped over the fact that TTEST2() (and
macros that eventually call it, such as TCHECK2() doesn't,
in 3.7.1, handle the case where the length is so large
that "snapend - l" underflows, but that shouldn't happen
with correctly-formed NFS requests.

Nevertheless, I'd suggest trying the current CVS version
(snapshots of which can be downloaded from the tcpdump.org
site), as that particular bug is fixed in the current CVS
version, so that'd at least determine whether that was the
problem or not. (If the offending NFS request was sent to
the machine on which you're running tcpdump, the copy given
to tcpdump might well be malformed - the Linux NFS code
has been known to mangle some NFS file names "in place", for
convenience when dissecting the NFS request or reply, in
such a way that programs capturing with a capture socket,
such as tcpdump or other libpcap-based programs, see the
mangled packet, not the packet as it arrived at the
machine. Sigh....)