nfs: fix failure to parse EXCHANGE_ID arguments

The exchange_id spo_must_enforce/spo_must_allow bitmaps are exceeding
this arbitrary MAX_BITMAPS constant, causing EXCHANGE_ID parsing to
fail.

Even in the case of attributes we may need more than 4 words soon, even
if we don't I'm not sure if it's actually illegal to zero-pad them out
to something longer, and even if that is illegal I don't think it's
really helpful of wireshark to stop parsing.

Keep the constant just as a sanity check but make it really large.

Ping-Bug: 10649
Change-Id: I3dff3ebde2d7f74f8cbe60a92c853463da66ae6a
Reviewed-on: https://code.wireshark.org/review/5144
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This commit is contained in:
J. Bruce Fields 2014-10-30 14:53:07 -04:00 committed by Michael Mann
parent e4b0141769
commit 8375a669f2
1 changed files with 7 additions and 8 deletions

View File

@ -6864,15 +6864,14 @@ static value_string_ext fattr4_names_ext = VALUE_STRING_EXT_INIT(fattr4_names);
#define FATTR4_BITMAP_ONLY 0
#define FATTR4_DISSECT_VALUES 1
/* As of NFSv4.1 (RFC 5661) The maximum number of attribute bitmaps is 3 in that NFSv4.1 introduced
* attribute numbers in excess of 63 (e.g., FATTR4_FS_CHARSET_CAP = 76):
*
* 1 2 3
* +-------------+----------+----------+----------+
* | num_bitmaps | 31 .. 0 | 63 .. 32 | 95 .. 64 |
* +-------------+----------+----------+----------+
/*
* Bitmaps are currently used for attributes and state_protect bits.
* Currently we don't expect more than 4 words, but future protocol
* revisions might add more bits, and in theory an implementation
* might legally zero-pad a bitmask out to something longer. We keep
* a generous maximum here just as a sanity check:
*/
#define MAX_BITMAPS 3
#define MAX_BITMAPS 100
/* Display each attrmask bitmap and optionally dissect the value.
*/