Check mstp_len before dereferencing

[anarcat]

During STP processing, we have a special handler for SPB (Shortest
Path Bridging) which parses a part of the packet for that specific
protocol. To find the length of that part of the packet (spb_len),
it uses the mstp_len variable to find where that value is
stored. Since mstp_len is unpacked from the packet earlier, it is a
user-controlled value and so, the pointer to sbp_len can also be
user-controlled.

We therefore need to check that we can extract it safely, using the
ND_TCHECK_16BITS macro, as per Code style and generic remarks in
the CONTRIBUTING document. The pointer taken to extract mstp_len
itself is checked, but, oddly, even though the comments say
sbp_len is validated as well, the macro call is missing.

This fixes the symptoms described by CVE-2017-11108 in my tests, but
someone with e deeper knowledge of the code should review this to
confirm it is the correct solution.

Closes: #616

[anarcat]

also note that there may be other branches of the stp code that are vulnerable to similar issues. i haven't audited the whole thing, just the part reported as vulnerable.

[infrastation]

Commit d9e65de is a more complete solution to this problem, it is now available in tcpdump release 4.9.1. Thank you very much for the pull request, please send any future security reports to security@tcpdump.org.