Re: Possible initialization error in libpcap

[Guy Harris <guy () alum mit edu>]

On Jan 8, 2013, at 1:58 PM, Derek Cole <derek.cole () gmail com> wrote:

> I am not sure this is the right mailing list for this or not,

It is.  "tcpdump-workers" is actually a combination of:

        "tcpdump-users" - users of tcpdump;

        "tcpdump-workers" - developers of tcpdump;

        "libpcap-users" - "users" of libpcap, i.e. developers of programs using libpcap (including tcpdump) asking 
questions about using libpcap;

        "libpcap-workers" - developers of libpcap.

> I am trying to debug some software that is using libpcap, with valgrind.

This is presumably on FreeBSD, as per your StackOverflow question at

        http://stackoverflow.com/questions/14218085/valgrind-errors-with-pcap-initialization

Presumably this is a port of valgrind to FreeBSD, as

> I am not able to get my software to launch, because valgrind is returning the
> dump at the bottom of the email.

Valgrind is complaining about several uninitialized variables, *and* about "unhandled ioctl 0x20004269 with no 
size/direction hints".  0x20004269 is _IO('B', 105), which is BIOCPROMISC.  BIOCPROMISC takes no arguments, so there is 
no size or direction.  However, an ioctl that takes arguments that aren't a simple fixed-size blob would also have no 
size/direction hints, so valgrind doesn't just assume there's nothing to check.  If that warning is causing a problem, 
you'll have to write a wrapper for that ioctl to let valgrind know that there are no arguments and therefore that no 
references to memory are made by it.

In your StackOverflow question, valgrind also complains about

> WARNING: unhandled syscall: 522
> --4765-- You may be able to write your own handler.
> --4765-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --4765-- Nevertheless we consider this a bug.  Please report
> --4765-- it at http://valgrind.org/support/bug_reports.html.

Yes, that's pselect().  I'm not sure why that's being called, unless select() is now a wrapper around it, but you may 
have to write a wrapper for that as well.

> As far as I can tell, I think all of the parameters I am passing are in fact initialized, so is there a problem in
> pcap itself?

Possibly, *IF* there's an issue with ioctl arguments being used.

Unfortunately, there aren't any line numbers, but I'm guessing that "???" is pcap_activate_bpf(), which is the module 
that implements pcap_activate() on systems with BPF (*BSD, OS X, AIX).

Looking at the code, there is one issue with an ioctl used for the memory-mapped capture mechanism in FreeBSD - the 
argument to BIOCGETZMAX is a size_t, but libpcap is passing a pointer to a u_int.  That shouldn't cause an 
uninitialized-byte variable, as it's *writing* the variable, not *reading* it, but it *does* need to be fixed so that 
random crap isn't overwritten on the stack on 64-bit platforms.

BIOCSETIF is being passed a pointer to a not-completely-initialized struct ifreq; however, the only part that's 
actually looked at in the structure, the interface name, *is* initialized.

I'm not sure what the

> ==4765== Conditional jump or move depends on uninitialised value(s)
> ==4765==    at 0x1A408DD: ??? (in /lib/libpcap.so.8)
> ==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
> ==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
> ==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
> ==4765==    by 0x120FE6A: driver_init (recfm.c:387)
> ==4765==    by 0x402633: main (driver.c:224)
> ==4765==  Uninitialised value was created by a heap allocation
> ==4765==    at 0x1008DAB: malloc (vg_replace_malloc.c:274)
> ==4765==    by 0x1A4013E: ??? (in /lib/libpcap.so.8)
> ==4765==    by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
> ==4765==    by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
> ==4765==    by 0x1822DB7: pcap_init (pcaputil.c:77)
> ==4765==    by 0x120FE6A: driver_init (recfm.c:387)
> ==4765==    by 0x402633: main (driver.c:224)

complaint is about.  It *might* be due to valgrind not understanding BIOCGDLTLIST, which is not a simple ioctl (you 
pass into it a structure containing a length and a pointer, and the kernel fills in the array pointed to by the pointer 
with a number of elements limited by the length).

So I suspect most if not all of your problems are due to valgrind not understanding BPF ioctls, not due to actual 
problems in your code or in libpcap.

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers