fix: uninitialized read in ipv6_address_rule when "." has no preceding h16#994
Conversation
|
An automated preview of the documentation is available at https://994.url.prtest2.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-05-13 04:17:14 UTC |
|
GCOVR code coverage report https://994.url.prtest2.cppalliance.org/gcovr/index.html Build time: 2026-05-13 04:29:37 UTC |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #994 +/- ##
========================================
Coverage 99.12% 99.12%
========================================
Files 155 154 -1
Lines 10085 10085
========================================
Hits 9997 9997
Misses 88 88
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
356e2cc to
490bd36
Compare
fix #993
Parsing a URI whose IPv6 host contains
.with no precedingh16(for examplehttps://[::.) read uninitialized memory. The IPv6 rule'sbytesbuffer is filled ash16groups are parsed; when a.was encountered immediately after::(or at the very start), the parser tried to validate it as the first octet of an embedded IPv4 by callingmaybe_octet(&bytes[2*(7-n)]), but those bytes had never been written.In a constexpr context the compiler catches this as a hard error (the example from the issue):
At runtime it is undefined behavior.
The fix: In
include/boost/url/rfc/impl/ipv6_address_rule.hpp, the.branch now returnserror::invalidbefore themaybe_octetread when noh16has been parsed in the current segment. The parser already maintains a flagcthat means "anh16was parsed in the current segment" (set true after eachh16, reset to false after::), which is exactly the condition needed.This eliminates the uninitialized read on every reachable path while preserving acceptance of valid inputs like
::1.2.3.4(wherecistrueafter parsing the leading1).