Make assignment operators panic safe #71
Merged
Conversation
This file contains 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
Can you explain how? This should not be possible, because there is no unsafe code executed in these methods. |
|
Oh, I understand now. During unwinding, or if the panic is caught, a Good catch, and thanks! |
mbrubeck
added a commit
that referenced
this pull request
Dec 6, 2020
Release notes: * Make assignment operators panic safe (#71). This fixes a bug that could cause undefined behavior in safe code.
mbrubeck
added a commit
that referenced
this pull request
Dec 6, 2020
Release notes: * Make assignment operators panic safe (#71). This fixes a bug that could cause undefined behavior in safe code.
mbrubeck
added a commit
to mbrubeck/advisory-db
that referenced
this pull request
Dec 6, 2020
…erators After using an assignment operators such as `NotNat::add_assign`, `NotNan::mul_assign`, etc., it was possible for the resulting `NotNan` value to contain a `NaN`. This could cause undefined behavior in safe code, because the safe `NotNan::cmp` method contains internal unsafe code that assumes the value is never `NaN`. (It could also cause undefined behavior in third-party unsafe code that makes the same assumption, as well as logic errors in safe code.) This was mitigated starting in version 0.4.0, by panicking if the assigned value is NaN. However, in affected versions from 0.4.0 onward, code that continued after using unwinding to catch this panic could still observe the invalid value and trigger undefined behavior. The flaw is fully corrected in versions 1.1.1 and 2.0.1, by ensuring that the assignment operators panic without modifying the operand, if the result would be `NaN`. Fix details: reem/rust-ordered-float#20 reem/rust-ordered-float#71
mbrubeck
added a commit
to mbrubeck/advisory-db
that referenced
this pull request
Dec 6, 2020
…erators After using an assignment operators such as `NotNat::add_assign`, `NotNan::mul_assign`, etc., it was possible for the resulting `NotNan` value to contain a `NaN`. This could cause undefined behavior in safe code, because the safe `NotNan::cmp` method contains internal unsafe code that assumes the value is never `NaN`. (It could also cause undefined behavior in third-party unsafe code that makes the same assumption, as well as logic errors in safe code.) This was mitigated starting in version 0.4.0, by panicking if the assigned value is NaN. However, in affected versions from 0.4.0 onward, code that continued after using unwinding to catch this panic could still observe the invalid value and trigger undefined behavior. The flaw is fully corrected in versions 1.1.1 and 2.0.1, by ensuring that the assignment operators panic without modifying the operand, if the result would be `NaN`. Fix details: reem/rust-ordered-float#20 reem/rust-ordered-float#71
mbrubeck
added a commit
to mbrubeck/advisory-db
that referenced
this pull request
Dec 6, 2020
…erators After using an assignment operators such as `NotNan::add_assign`, `NotNan::mul_assign`, etc., it was possible for the resulting `NotNan` value to contain a `NaN`. This could cause undefined behavior in safe code, because the safe `NotNan::cmp` method contains internal unsafe code that assumes the value is never `NaN`. (It could also cause undefined behavior in third-party unsafe code that makes the same assumption, as well as logic errors in safe code.) This was mitigated starting in version 0.4.0, by panicking if the assigned value is NaN. However, in affected versions from 0.4.0 onward, code that continued after using unwinding to catch this panic could still observe the invalid value and trigger undefined behavior. The flaw is fully corrected in versions 1.1.1 and 2.0.1, by ensuring that the assignment operators panic without modifying the operand, if the result would be `NaN`. Fix details: reem/rust-ordered-float#20 reem/rust-ordered-float#71
|
Published ordered-float 1.1.1 and 2.0.1, and submitted a security advisory: rustsec/advisory-db#514 |
|
I haven't fixed this on the ordered-float 0.5 branch, because backporting is non-trivial and the test suite on that branch uses unstable features that are broken in modern Rust toolchains. There are only a few actively-developed crates still using ordered-float 0.5, and the ones with source code available (descartes, prolog_parser, scryer-prolog) are not impacted by this bug. Anyone using ordered-float 0.5 should upgrade to a newer version as soon as possible. |
badboy
added a commit
to badboy/rkv
that referenced
this pull request
Jun 7, 2022
See GHSA-566x-hhrf-qf8m This was fixed in v1.1.1, see reem/rust-ordered-float#71 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Current behavior allows UB in safe code.