-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[BUG] Unsoundness: try_parse_{4,8}digits
appear to advance iterators out of bounds
#101
Labels
A-sec
Issues with potential security implications.
bug
Something isn't working
high priority
High priority
Comments
Alexhuszagh
added
high priority
High priority
A-sec
Issues with potential security implications.
labels
Sep 9, 2024
This was resolved as of commit #103. If I'm wrong about this, please re-open this or create another issue. All checks now should be done without any debug asserts, using: /// Try to read a the next four bytes as a u32.
/// This advances the internal state of the iterator.
#[inline(always)]
pub fn read_u32(&self) -> Option<u32> {
if Self::IS_CONTIGUOUS && self.as_slice().len() >= mem::size_of::<u32>() {
// SAFETY: safe since we've guaranteed the buffer is greater than
// the number of elements read. u32 is valid for all bit patterns
unsafe { Some(self.read_unchecked()) }
} else {
None
}
}
/// Try to read the next eight bytes as a u64
/// This advances the internal state of the iterator.
#[inline(always)]
pub fn read_u64(&self) -> Option<u64> {
if Self::IS_CONTIGUOUS && self.as_slice().len() >= mem::size_of::<u64>() {
// SAFETY: safe since we've guaranteed the buffer is greater than
// the number of elements read. u64 is valid for all bit patterns
unsafe { Some(self.read_unchecked()) }
} else {
None
}
} |
This was referenced Sep 9, 2024
This was referenced Sep 16, 2024
This was referenced Sep 26, 2024
This was referenced Nov 11, 2024
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-sec
Issues with potential security implications.
bug
Something isn't working
high priority
High priority
BytesIter::read
is documented as advancing the iterator's state:rust-lexical/lexical-util/src/iterator.rs
Lines 123 to 125 in 09c686b
However, the
try_parse_4digits
andtry_parse_8digits
methods advance the iterator's state manually after reading, without any other apparent length checks:rust-lexical/lexical-parse-integer/src/algorithm.rs
Lines 220 to 223 in 09c686b
rust-lexical/lexical-parse-integer/src/algorithm.rs
Lines 293 to 295 in 09c686b
This is unsound according to the docs of
step_by_unchecked
:rust-lexical/lexical-util/src/iterator.rs
Lines 131 to 133 in 09c686b
Skimming around for actual implementations, it appears that
read
may not actually advance the state as advertised, which could explain how this has gone unnoticed so far. Note the absence of any mutation ofself.index
, contrary to the doc comment:rust-lexical/lexical-util/src/noskip.rs
Lines 102 to 118 in 09c686b
The text was updated successfully, but these errors were encountered: