#145 setsockopt(optval) points to uninitialised byte(s)

[Luis MartinGarcia]

I've been trying to track down a problem reported by valgrind. When
using pcap_set_filter() on Linux, valgrind complains about a
setsockopt() call that uses a pointer to some uninitialized memory. The
message I get is the following:

==22214== Syscall param socketcall.setsockopt(optval) points to
uninitialised byte(s)
==22214== at 0x62F774A: setsockopt (syscall-template.S:82)
==22214== by 0x4E33B85: ??? (in /usr/lib/libpcap.so.1.0.0)
==22214== by 0x4E33D0D: ??? (in /usr/lib/libpcap.so.1.0.0)
==22214== by 0x432253: nsock_pcap_set_filter (in /usr/local/bin/nping)
==22214== by 0x432557: nsock_pcap_open (in /usr/local/bin/nping)
==22214== by 0x4295FF: ProbeMode::start() (in /usr/local/bin/nping)
==22214== by 0x40B2E1: main (in /usr/local/bin/nping)

(I've been able to reproduce this message in other tools that use pcap,
so this isn't implementation specific).

Also, I have tracked down the problem to
pcap-linux.c::pcap_setfilter_linux_common(). By adding a simple memset()
call, I am able to get rid of the message. I attach a patch that fixes
this issue. Please, consider integrating it into mainstream.

[Luis MartinGarcia]

[Guy Harris]

Err, umm, so where exactly does valgrind get the impression that there's uninitialized data in that structure?

At least in the trunk, if SO_ATTACH_FILTER is defined, pcap_setfilter_linux_common() will either set fcode.len to 0 and fcode.filter to NULL, if handle->fcode.bf_len > USHRT_MAX, or will call fix_program(), which will return -1 if it can't mallocate the program or will set fcode->len and fcode->filter otherwise, and pcap_setfilter_linux_common() will just return -1 if fix_program() returns -1.

And, at least in the version of the trunk of the Linux kernel that I have, "struct sock_fprog" is

struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
unsigned short len; /* Number of filter blocks */
struct sock_filter __user *filter;
};

which has no other members to set. There's padding between "len" and "filter", but if valgrind doesn't understand that it's padding, not data, and thus doesn't *need* to be initialized, it needs to be fixed to do so.

[Guy Harris]

This also fixes the issue:

https://bugs.kde.org/show_bug.cgi?id=318203

By adding some code to Valgrind that understands how setsockopt(SOL_SOCKET, SO_ATTACH_FILTER) actually works, I can not only get rid of the message, but add messages about cases that the old code didn't catch.

Please consider voting that bug up, to encourage inclusion of the fix in a future release of Valgrind.

[Denis Ovsienko]

Administrators of the "libpcap" SourceForge project have superseded this tracker item (formerly artifact 3108546, now bug 145) with issue 147 of the "libpcap" GitHub project.