Skip to content

Fix is_valid_ip_address raising ValueError on embedded null byte - #2185

Merged
micafer merged 3 commits into
apache:trunkfrom
Ashishjob:fix-is-valid-ip-address-null-byte
Sep 2, 2026
Merged

Fix is_valid_ip_address raising ValueError on embedded null byte#2185
micafer merged 3 commits into
apache:trunkfrom
Ashishjob:fix-is-valid-ip-address-null-byte

Conversation

@Ashishjob

Copy link
Copy Markdown
Contributor

Summary

libcloud.utils.networking.is_valid_ip_address is a predicate that should return True/False for whether a string is a valid IP address. It calls socket.inet_pton and catches OSError to return False for malformed input.

However, socket.inet_pton raises ValueError (not OSError) when the address string contains an embedded null byte, e.g. "1.2.3.4\x00". That ValueError was not caught, so instead of returning False the function propagated an exception to the caller:

>>> from libcloud.utils.networking import is_valid_ip_address
>>> is_valid_ip_address("1.2.3.4")
True
>>> is_valid_ip_address("1.2.3.4\x00")
ValueError: embedded null character   # expected: False

Fix

Catch ValueError as well and return False, since a string with an embedded null byte is not a valid address.

Tests

Added regression cases (IPv4 and IPv6 addresses containing embedded null bytes) to the existing test_is_valid_ip_address. Verified they fail before the change (uncaught ValueError) and pass after it. Full libcloud/test/test_utils.py passes (23 passed, 1 skipped).

Changelog

Changelog entry added under Common in a follow-up commit referencing this PR number.

Ashishjob and others added 2 commits September 2, 2026 01:48
socket.inet_pton raises ValueError (not OSError) when the address string
contains an embedded null byte, e.g. "1.2.3.4\x00". is_valid_ip_address only
caught OSError, so such input propagated the ValueError instead of being
reported as invalid. A validity predicate should return False for a malformed
address, never raise.

Catch ValueError as well and add regression cases (IPv4 and IPv6 addresses
with embedded null bytes) to test_is_valid_ip_address.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

@micafer micafer left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@codecov-commenter

codecov-commenter commented Sep 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.59%. Comparing base (8ffc0a3) to head (1e4c562).

Additional details and impacted files
@@           Coverage Diff           @@
##            trunk    #2185   +/-   ##
=======================================
  Coverage   83.59%   83.59%           
=======================================
  Files         352      352           
  Lines       81852    81854    +2     
  Branches     8771     8772    +1     
=======================================
+ Hits        68417    68421    +4     
+ Misses      10562    10561    -1     
+ Partials     2873     2872    -1     
Files with missing lines Coverage Δ
libcloud/test/test_utils.py 98.30% <ø> (ø)
libcloud/utils/networking.py 97.06% <100.00%> (+0.18%) ⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@micafer

micafer commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Tests are failing could you check it?

CPython's socket.inet_pton raises ValueError on an embedded null byte while
PyPy silently accepts it, so catching ValueError alone left is_valid_ip_address
returning True for e.g. "1.2.3.4\x00" on PyPy (and failing the regression test
there). A string with a null byte is never a valid address, so reject it
explicitly before calling inet_pton, giving the same result on every
interpreter.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@micafer
micafer merged commit 52b5236 into apache:trunk Sep 2, 2026
17 checks passed
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.

3 participants