| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
NetBSD 9.0 defines struct bpf_aux_data in net/bpf.h; that gets included
by pcap-bpf.c, along with pcap-int.h, which causes a collision.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Most BPF arithmetic is unsigned, but negation can't be unsigned;
respecify it as subtracting the value from 0U, so that 1) we don't get
compiler warnings about negating an unsigned value and 2) don't get
UBSan warnings about the result of negating 0x80000000 being undefined.
Credit to OSS-Fuzz for finding these issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some processors treat shifts greater than the width of the shifted
operand as setting the destination to 0, some others treat it as a shift
modulo the width.
C says it's undefined, and most if not all implementations make it work
the way the target processor works.
We treat it as setting the destination to 0, regardless of how the
processor on which we're running works.
Credit to OSS-Fuzz for finding this issue.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If net/bpf.h declares bpf_filter() one way and libpcap defines it
another way, even pcap-bpf.c needs a declaration that matches how
libpcap defines it, not how net/bpf.h (mistakenly) declares it.
("Mistakenly" because it should *not* be declaring the kernel's version
of bpf_filter() unless it's being used in a *kernel* build; other *BSDs,
and macOS, declare it only in kernel builds by testing for a #define
such as KERNEL or KERNEL_PRIVATE, but NetBSD doesn't - it *should*, but
it doesn't.)
So we rename the internal-to-pcap filtering routine as pcap_filter(),
which is not exported from libpcap, and have bpf_filter() be a wrapper
around pcap_filter() that is exported.
Use pcap_filter(), rather than bpf_filter(), for all filtering inside
libpcap (except for filtering that uses bpf_filter_with_aux_data(),
which we rename pcap_filter_with_aux_data()).
Do the same for bpf_validate(), which is *also* declared in net/bpf.h,
even for non-kernel builds, in NetBSD.
As we're not exporting pcap_filter_with_aux_data(), don't even *declare*
it in a public header; don't declare struct bpf_aux_data in a public
header, either. That way we can change it without worrying about
breaking APIs or ABIs; we may do that if, for example, we want to
support the "inbound" and "outbound" filters when reading pcapng files,
adding a direction indicator to that structure.
Declare bpf_filter() in pcap/bpf.h even on NetBSD and QNX; pcap-bpf.c
doesn't include pcap/bpf.h (it sets a #define to force pcap/pcap.h not
to include it), so we won't get any collisions if net/bpf.h (which it
does include) declares it. The only collisions will occur in programs
that include *both* pcap/pcap.h or pcap/bpf.h *and* net/bpf.h, and that
will occur only if net/bpf.h declares bpf_filter() even when building
userland code, and the correct fix for *that* is to fix net/bpf.h not to
declare them in non-kernel builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Don't put struct bpf_aux_data there, either.
bpf_filter_with_aux_data() is an internal-only routine, and struct
bpf_aux_data is a data structure subject to change in the future; don't
make them public, so that we *can* change it in the future without
having to worry about breaking APIs or ABIs.
(Note to any upstream packager of libpcap: if you've made it public,
so that it's exported by a shared libary, that was a mistake, so undo
it.)
|
| | |
|
| | |
|
| |
|
|
| |
No point in duplicating the unaligned-big-endian-extraction stuff.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This should squelch some undefined behavior warnings, because, on
platforms where you *can* do unaligned fetches, we just suppress that
warning.
While we're at it, use C99-style integer types, which we now require;
pcap/pcap-inttypes.h ensures they're defined on Windows, and we simply
assume <inttypes.h> defines them on UN*X (if it doesn't, we don't
support your UN*X any more).
|
| | |
|
|
|
Fix autotools .devel failure in OOT-build while at it
|
