Have nd_push_buffer() take a snapshot length, not a snapshot end, as
its last argument.
Replace nd_push_snapend() and nd_change_snapend() with nd_push_snaplen()
and nd_change_snaplen(), both of which take a pointer into the packet
buffer and snapshot length relative to that pointer as arguments. Have
those routines check the snapshot length to make sure it's not bigger
than the number of bytes in the packet past the pointer, and silently
ignore the requst if it is.
Using a length rather than a pointer avoids the possibility of the
calculation of the snapshot end overflowing and resulting in a snapshot
end *before* the point in the buffer.
Add a test for this, with a capture file containing an IPv6 packet with
an extremely large "jumbo" packet size.
Revert the "Make sure we don't set the snapend before the beginning of
the packet." changes, as they no longer apply with this change (which
also makes sure we don't set the snapend before the beginning of the
packet).
If a caller attempts to set it after the current snapend, just silently
ignore the attempt.
If they try to set it before the beginning of the packet, report it as a
bug and quit dissection. Add a new setjmp() return value meaning "bug"
rather than "truncated packet", add an "nd_bug_longjmp()" routine for
reporting bugs where we should quit dissecting, and use that in this
case.
Remove remaining references to them as being MPLS-related;
draft-bonica-icmp-mpls-02 referred to them as "ICMP Extensions for
MultiProtocol Label Switching", but draft-bonica-internet-icmp-00
redefined it as a general extension mechanism, not MPLS-related, and
that draft eventually became RFC 4884.
draft-bonica-icmp-mpls-02 also defined class 2 objects as objects
containing the remaining packet information past the first 128 bytes;
that never became part of an RFC and class 2 was redefined as an
"Interface Information Object" in RFC 5837.
Give some of these details in comments, and move some
extension-related definitions among the rest of the extension stuff.
To quote a comment from a 2003 commit that removed them the first time:
removed people who shouldn't be bugged since they aren't
actively committing code now.
As it turns out, the same warnings reproduce with other Clang versions
(at least 11) and other illumos distributions (at least OmniOS), so omit
Clang version in the pattern.
Fix these cppcheck warnings:
addrtoname.c:1288:11: warning: Checking if unsigned expression 'num'
is less than zero. [unsignedLessThanZero]
if (num <= 0) {
^
addrtoname.c:1308:11: warning: Checking if unsigned expression 'num'
is less than zero. [unsignedLessThanZero]
if (num <= 0) {
^
For some reason pcap fuzzers just *love* to fuzz the "link-layer type
plus other stuff" part of the pcap file header. That can produce a file
that has non-zero values in reserved fields, which means it can get
rejected well before being handed to anything for dissection.
Clear out one of the reserved parts of that field, as we'll be changing
libpcap to check for non-zero values and reporting an error.
Fix this cppcheck warning:
print-resp.c:215:22: warning: Checking if unsigned expression 'length'
is less than zero. [unsignedLessThanZero]
if(!bp || length <= 0)
^
Fix this cppcheck warning:
print-tcp.c:711:20: warning: Checking if unsigned expression 'length'
is less than zero. [unsignedLessThanZero]
if (length <= 0)
^
