-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[beta] std: Check for overflow in str::repeat
#54398
Conversation
This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in rust-lang#48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release, and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space, there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue, we'll be making a formal post to the Rust security list once these commits have been merged.
r? @Kimundi (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ |
📌 Commit 4d1d1be has been approved by |
⌛ Testing commit 4d1d1be with merge a1b6192da5d5ba95dd5bd59f97e50a6c57d812b6... |
💔 Test failed - status-appveyor |
@bors: retry 3 hr timeout, presumably repopulating caches |
[beta] std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release, and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space, there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue, we'll be making a formal post to the Rust security list once these commits have been merged.
☀️ Test successful - status-appveyor, status-travis |
This commit fixes a buffer overflow issue in the standard library
discovered by Scott McMurray where if a large number was passed to
str::repeat
it may cause and out of bounds write to the buffer of aVec
.This bug was accidentally introduced in #48657 when optimizing the
str::repeat
function. The bug affects stable Rust releases 1.26.0 to1.29.0. We plan on backporting this fix to create a 1.29.1 release, and
the 1.30.0 release onwards will include this fix.
The fix in this commit is to introduce a deterministic panic in the case of
capacity overflow. When repeating a slice where the resulting length is larger
than the address space, there’s no way it can succeed anyway!
The standard library and surrounding libraries were briefly checked to see if
there were othere instances of preallocating a vector with a calculation that
may overflow. No instances of this bug (out of bounds write due to a calculation
overflow) were found at this time.
Note that this commit is the first steps towards fixing this issue,
we'll be making a formal post to the Rust security list once these
commits have been merged.