Skip to content
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

Update Patched Fix memoffset allows reading uninitialized memory #3294

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

imhunterand
Copy link

@imhunterand imhunterand commented Apr 16, 2024

memoffset allows attempt of reading data from address 0 with arbitrary type. This behavior is an undefined behavior because address 0 to std::mem::size_of may not have valid bit-pattern with T. Old implementation dereferences uninitialized memory obtained from std::mem::align_of. Older implementation prior to it allows using uninitialized data obtained from std::mem::uninitialized with arbitrary type then compute offset by taking the address of field-projection. This may also result in an undefined behavior for "father" that includes (directly or transitively) type that does not allow to be uninitialized.

        // of the field check we did above.
        #[allow(unused_unsafe)] // for when the macro is used in an unsafe block
        unsafe {
            _memoffset__raw_const!((*($base as *const $parent)).$field)
        }
/// `raw_const!`, or just ref-then-cast when that is not available.
#[cfg(feature = "unstable_raw")]
#[macro_export]
#[doc(hidden)]
macro_rules! _memoffset__raw_const {
    ($path:expr) => {{
        $crate::ptr::raw_const!($path)
    }};
}
#[cfg(not(feature = "unstable_raw"))]
#[macro_export]
#[doc(hidden)]
macro_rules! _memoffset__raw_const {
    ($path:expr) => {{
        // This is UB because we create an intermediate reference to uninitialized memory.
        // Nothing we can do about that without `raw_const!` though.
        &$path as *const _
    }};
}
  • Targeted PR against correct branch (see CONTRIBUTING.md)

  • Linked to github-issue with discussion and accepted design OR link to spec that describes this work.

  • Wrote tests

  • Updated relevant documentation (docs/)

  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md

  • Reviewed Files changed in the github PR explorer


For Admin Use:

  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)
  • Reviewers Assigned
  • Squashed all commits, uses message "Merge PR #XYZ: [title]" (coding standards)

memoffset allows attempt of reading data from address 0 with arbitrary type. This behavior is an undefined behavior because address 0 to std::mem::size_of<T> may not have valid bit-pattern with T. Old implementation dereferences uninitialized memory obtained from std::mem::align_of. Older implementation prior to it allows using uninitialized data obtained from std::mem::uninitialized with arbitrary type then compute offset by taking the address of field-projection. This may also result in an undefined behavior for "father" that includes (directly or transitively) type that [does not allow to be uninitialized](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html).

```
        // of the field check we did above.
        #[allow(unused_unsafe)] // for when the macro is used in an unsafe block
        unsafe {
            _memoffset__raw_const!((*($base as *const $parent)).$field)
        }
/// `raw_const!`, or just ref-then-cast when that is not available.
#[cfg(feature = "unstable_raw")]
#[macro_export]
#[doc(hidden)]
macro_rules! _memoffset__raw_const {
    ($path:expr) => {{
        $crate::ptr::raw_const!($path)
    }};
}
#[cfg(not(feature = "unstable_raw"))]
#[macro_export]
#[doc(hidden)]
macro_rules! _memoffset__raw_const {
    ($path:expr) => {{
        // This is UB because we create an intermediate reference to uninitialized memory.
        // Nothing we can do about that without `raw_const!` though.
        &$path as *const _
    }};
}
```
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.

None yet

1 participant