Fix panics in GetCIDRFromIPRange and IntegerToIP on valid inputs - #821
Fix panics in GetCIDRFromIPRange and IntegerToIP on valid inputs#821gaoflow wants to merge 1 commit into
Conversation
GetCIDRFromIPRange assumed a 16-byte net.IP. A 4-byte (To4) or mixed-length pair panicked with "index out of range" in rangeToCIDRs, because a normalized 16-byte spanning IP was compared against the raw 4-byte input, spuriously entering the partition branch which then dereferenced an empty slice. The same length mismatch also made the initial start>end check wrongly reject valid mixed-length ranges. Normalize both IPs to 16-byte at the entry point. IntegerToIP panicked with "index out of range [-1]" when ipInt >= 2^bits, since the copy loop indexed past the destination. Bound the copy to the destination width so oversized values wrap (mod 2^bits) instead of panicking. Both are reachable through the library's own API: net.ParseCIDR and IntegerToIP return 4-byte IPs that feed straight back into GetCIDRFromIPRange.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
WalkthroughThe changes make integer-to-IP conversion safe for oversized values and normalize IP range inputs before CIDR generation. Tests cover overflow wrapping, IPv4 byte-length variations, representation parity, and exact CIDR range coverage. ChangesIP and CIDR corrections
Estimated code review effort: 3 (Moderate) | ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
GetCIDRFromIPRangeandIntegerToIPhard-panic on legitimatenet.IPinputs. Both are reachable through the library's own API —net.ParseCIDRandIntegerToIPreturn 4-byte IPs that feed straight back in.Root cause is one class: an unchecked byte-length / magnitude assumption.
GetCIDRFromIPRangeassumes a 16-byte IP. With a 4-byte or mixed pair,rangeToCIDRscompares a normalized 16-byte spanning IP against the raw 4-byte input, spuriously takes the partition branch, and dereferences an empty slice. The same mismatch makes the initialstart > endcheck wrongly reject valid mixed-length ranges (e.g. a 4-byte start with a 16-byte end). Fixed by normalizing both IPs to 16-byte at the entry point.IntegerToIPindexes past the destination whenipInt >= 2^bits. Bounded the copy to the destination width so oversized values wrap (mod 2^bits) instead of panicking; in-range values are unchanged.Tested: new table tests for 4-byte/mixed/
IntegerToIP-output/oversized cases, plus a tiling check that 4-byte, 16-byte and mixed inputs all yield the same aligned, contiguous, non-overlapping CIDR set covering the range exactly (also cross-checked againstIpRangeToCIDR).go test ./...,go vetpass.Note the repo's recent merges look dependency-only, so review may be slow — flagging since this is a DoS-on-valid-input in a tool that processes untrusted ranges.
Summary by CodeRabbit
Bug Fixes
Tests