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

guyharris opened this Issue Apr 15, 2013 · 2 comments


None yet

1 participant

The Tcpdump Group member

Converted from SourceForge issue 3108546, submitted by luis_mg

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/
==22214== by 0x4E33D0D: ??? (in /usr/lib/
==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.

The Tcpdump Group member

Submitted by 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.

The Tcpdump Group member

Submitted by guy_harris

This also fixes the issue:

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.

@guyharris guyharris closed this Apr 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment