| Bug ID |
11207
|
| Summary |
OpenFlow Match Experimenter Field uses supplied length incorrectly
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86-64
|
| OS |
Ubuntu
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Wireshark 1.99.6 (9d5a9fb from master)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 4.8.6, with libpcap, with POSIX capabilities (Linux),
without libnl, with libz 1.2.8, with GLib 2.40.2, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT
Kerberos,
with GeoIP, without PortAudio, with AirPcap.
Running on Linux 3.13.0-52-generic, with locale C, with libpcap version 1.5.3,
with libz 1.2.8, with GnuTLS 2.12.23, with Gcrypt 1.5.3, without AirPcap.
AMD FX(tm)-8320 Eight-Core Processor (with SSE4.2)
Built using gcc 4.8.2.
--
When dissecting an OFPT_FLOW_MOD packet with an OFPXMC_EXPERIMENTER OXM field,
the packet-supplied Length of the OXM field data is supposed to include the
Experimenter ID itself; however, Wireshark is instead trying to dissect
information after the OXM body. This causes the following match fields and
instructions to be offset and incorrectly read.
For example, here is the output of such a packet:
OpenFlow 1.3
Version: 1.3 (0x04)
Type: OFPT_FLOW_MOD (14)
Length: 88
Transaction ID: 4025368488
Cookie: 0x0000000000000000
Cookie mask: 0x0000000000000000
Table ID: 0
Command: OFPFC_ADD (0)
Idle timeout: 0
Hard timeout: 0
Priority: 32768
Buffer ID: OFP_NO_BUFFER (0xffffffff)
Out port: 0
Out group: 0
Flags: 0x0000
.... .... .... ...0 = Send flow removed: False
.... .... .... ..0. = Check overlap: False
.... .... .... .0.. = Reset counts: False
.... .... .... 0... = Don't count packets: False
.... .... ...0 .... = Don't count bytes: False
Pad: 0000
Match
Type: OFPMT_OXM (1)
Length: 32
OXM field
Class: OFPXMC_OPENFLOW_BASIC (0x8000)
0100 110. = Field: OFPXMT_OFB_TUNNEL_ID (38)
.... ...0 = Has mask: False
Length: 8
Value: 0000000000000001
OXM field
Class: OFPXMC_EXPERIMENTER (0xffff)
0000 110. = Field: 6
.... ...1 = Has mask: True
Length: 12
Experimenter: 0x00001018
Unknown OXM body.
[Expert Info (Note/Undecoded): Unknown OXM body.]
[Unknown OXM body.]
[Severity level: Note]
[Group: Undecoded]
Instruction
Type: Unknown (12800)
Length: 0
Unknown instruction body.
[Expert Info (Note/Undecoded): Unknown instruction body.]
[Unknown instruction body.]
[Severity level: Note]
[Group: Undecoded]
In the last OXM field, the Length is specified as 12. According to the OF 1.3.4
specification (7.2.4, page 65), that length also includes the entire
instruction header (8 bytes, see assertion below) so the OXM body should only
be read as 4 bytes. Instead, it reads 12 bytes, including the first 8 bytes of
the Instruction struct data.
For reference, from the spec:
/* Instruction structure for experimental instructions */
struct ofp_instruction_experimenter {
uint16_t type; /* OFPIT_EXPERIMENTER */
uint16_t len; /* Length of this struct in bytes */
uint32_t experimenter; /* Experimenter ID which takes the same form as in
struct ofp_experimenter_header. */
/* Experimenter-defined arbitrary additional data. */
};
OFP_ASSERT(sizeof(struct ofp_instruction_experimenter) == 8)
For comparison, other OXM field classes have fixed lengths that include the
entire struct (type, len, and data of some sort):
/* Instruction structure for OFPIT_METER */
struct ofp_instruction_meter {
uint16_t type; /* OFPIT_METER */
uint16_t len; /* Length is 8. */
uint32_t meter_id; /* Meter instance. */
};
OFP_ASSERT(sizeof(struct ofp_instruction_meter) == 8);
You are receiving this mail because:
- You are watching all bug changes.