Skip to content

Fix panic on malformed OSPF packets#1229

Open
mohammadmseet-hue wants to merge 1 commit intogoogle:masterfrom
mohammadmseet-hue:fix-ospfv2-panic
Open

Fix panic on malformed OSPF packets#1229
mohammadmseet-hue wants to merge 1 commit intogoogle:masterfrom
mohammadmseet-hue:fix-ospfv2-panic

Conversation

@mohammadmseet-hue
Copy link
Copy Markdown

Summary

Validate PacketLength against actual data length in both OSPFv2 and OSPFv3 DecodeFromBytes, and add bounds checking in getLSAsv2/getLSAs before reading LSA headers.

Root cause: ospf.PacketLength from the packet header is trusted as a loop bound for Hello neighbors, DBDesc LSAs, LSRequests, and LSAck iterations. When PacketLength exceeds actual data length, reads go out of bounds. getLSAsv2 indexes data[offset+3] and data[offset+18:offset+20] without checking bounds.

Fix: Return an error if PacketLength > len(data). Check offset+20 <= len(data) in LSA parsing loops.

Panics fixed: 3 (Hello PacketLength overflow, DBDesc PacketLength overflow, LSUpdate with truncated LSA data)

All existing tests pass.

Validate PacketLength against actual data length in both OSPFv2 and
OSPFv3 DecodeFromBytes before using it as loop bounds. Add bounds
checking in getLSAsv2 and getLSAs before reading LSA headers.

Malformed packets with inflated PacketLength or NumOfLSAs caused index
out of range panics when the parser iterated beyond available data.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant