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

Soundness hole in Ptr::read_unaligned #1892

Open
Tracked by #1939
joshlf opened this issue Oct 12, 2024 · 2 comments
Open
Tracked by #1939

Soundness hole in Ptr::read_unaligned #1892

joshlf opened this issue Oct 12, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@joshlf
Copy link
Member

joshlf commented Oct 12, 2024

From what I can tell, it's not exercised anywhere in the codebase.

Ptr::read_unaligned permits reading from a shared pointer through UnsafeCells:

impl<'a, T, Aliasing, Alignment> MaybeAligned<'a, T, Aliasing, Alignment>
where
T: 'a + ?Sized,
Aliasing: invariant::Aliasing + invariant::AtLeast<invariant::Shared>,
Alignment: invariant::Alignment,
{
/// Reads the value from `MaybeAligned`.
#[must_use]
#[inline]
pub fn read_unaligned(self) -> T
where
T: Copy,
{
let raw = self.as_non_null().as_ptr();
// SAFETY: By invariant on `MaybeAligned`, `raw` contains
// validly-initialized data for `T`. The value is safe to read and
// return, because `T` is copy.
unsafe { core::ptr::read_unaligned(raw) }
}

We should either add an Immutable bound or an AliasingSafe bound.

@joshlf joshlf added the bug Something isn't working label Oct 12, 2024
joshlf added a commit that referenced this issue Oct 12, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 12, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 12, 2024
joshlf added a commit that referenced this issue Oct 12, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 12, 2024
joshlf added a commit that referenced this issue Oct 12, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 12, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 13, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
github-merge-queue bot pushed a commit that referenced this issue Oct 14, 2024
joshlf added a commit that referenced this issue Oct 14, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 14, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 14, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
joshlf added a commit that referenced this issue Oct 14, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
github-merge-queue bot pushed a commit that referenced this issue Oct 14, 2024
`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890
@joshlf joshlf mentioned this issue Oct 21, 2024
8 tasks
@Aditya-PS-05
Copy link
Contributor

Is the issue still open? Can you assign me this issue?

@joshlf
Copy link
Member Author

joshlf commented Nov 4, 2024

This is already fixed in 0.8 and a fix is in-progress in 0.9. Thanks for volunteering though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants