-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.0.0, 1.0.1, 1.1.0, 1.2.0, 1.3.0, 1.2.1, 1.2.2, 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.7.0, 1.8.0, 1.7.1, 1.9.0, 1.8.2, 1.8.3, 1.9.2, 1.10.0, 1.8.5, 1.8.6, 1.11.0, 1.12.0, 1.13.0, 1.13.1, 1.14.0, 1.12.1, 1.15.0, 2.0.0, 2.1.0
-
Component/s: Platform
-
Labels:None
Class org.onlab.packet.Data use all bytes from data buffer starting from offset up to the end of buffer during deserialization process instead of requested length bytes.
This issue happens during deserialization of an Ethernet frames with the short payload. If packet with broken data will be serialized back then packet will be fully broken.
Example
Input packet can be the following:
Ethernet header with IPv4 payload type with length 14 bytes: aa aa aa aa aa aa bb bb bb bb bb bb 08 00 IPv4 Header 20 bytes length with UDP payload: 45 00 00 2d cc cc 00 00 80 11 dd dd 0a 00 00 01 0a 00 00 02 UDP packet with 8 bytes header and 17 bytes payload: aa aa bb bb 00 19 dd dd 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Total Ethernet frame payload is 45 bytes. Ethernet frame payload can't be less then 46 bytes (Minimal Ethernet frame length if 64 bytes, where 14 bytes header, 4 bytes frame check sequence at the end of the frame and 46 bytes of the payload). As result the ONOS got the Ethernet frame padded with zeros and during deserialization UPD payload become 18 bytes length Data object.
If we want to serialize this packet back then UDP and IPv4 packets will recalculate own length basing on the Data payload length and during serialization will got packets with broken checksum.
Suggested solution
Use only length bytes of the data buffer during Data object deserialization.