Fix panic in GroupInfo::members#680
Open
jeremija wants to merge 1 commit into
Open
Conversation
jeremija
force-pushed
the
task/add-null-check-in-groupinfo-members
branch
3 times, most recently
from
531e6d2 to
4470b95
Compare
I recently observed undefined behavior in one of the projects I'm working on because [slice::from_raw_parts] is called without a null-check in `GroupInfo::members`. This undefined behavior was present when iterating over the resulting slice and it would just terminate prematurely when trying to chain multiple iterators. The function is pretty strict about what kind of pointers it accepts: > data must be non-null and aligned even for zero-length slices. This undefined behavior has become a panic in debug builds in [Rust 1.78.0]: > For example, slice::from_raw_parts requires an aligned non-null pointer. > The following use of a purposely-misaligned pointer has undefined behavior, > and while if you were unlucky it may have appeared to "work" in the past, > the debug assertion can now catch it: Cause is found in [rdkafka.c]. I see there are more uses of `slice::from_raw_parts` so I replaced all of them except a call to `Vec::from_raw_parts` which seems fine. I'd appreciate feedback! [slice::from_raw_parts]: https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html [Rust 1.78.0]: https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#asserting-unsafe-preconditions [rdkafka.c]: https://github.com/confluentinc/librdkafka/blob/95a542c87c61d2c45b445f91c73dd5442eb04f3c/src/rdkafka.c#L4668-L4670
jeremija
force-pushed
the
task/add-null-check-in-groupinfo-members
branch
from
4470b95 to
8b7ccac
Compare
Collaborator
|
@jeremija can you fix the conflicts reported here? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I recently observed undefined behavior in one of the projects I'm working on because slice::from_raw_parts is called without a null-check in
GroupInfo::members. This undefined behavior was present when iterating over the resulting slice and it would just terminate prematurely when trying to chain multiple iterators. The function is pretty strict about what kind of pointers it accepts:This undefined behavior has become a panic in debug builds in Rust 1.78.0:
Cause is found in rdkafka.c. I noticed there are more uses of
slice::from_raw_partsso I replaced all of them except a call toVec::from_raw_partswhich seems fine. I'd appreciate feedback!