Fix unsoundness of AtomicCell<*64> arithmetics on 32-bit targets that support Atomic*64 #781
Conversation
|
bors r+ |
781: Fix unsoundness of AtomicCell<*64> arithmetics on 32-bit targets that support Atomic*64 r=taiki-e a=taiki-e The alignment of u64/i64 on a 32-bit target can be smaller than AtomicU64/AtomicI64. 32-bit targets without Atomic*64 (#767) and 64-bit targets are not affected by this issue. Co-authored-by: Taiki Endo <[email protected]>
… support Atomic*64
taiki-e
force-pushed
the
atomic-cell-64-32
branch
from
19506ce
to
f7c378b
Compare
|
Canceled. |
|
bors r+ |
|
Build succeeded: |
786: Prepare for the next release r=taiki-e a=taiki-e - crossbeam-epoch 0.9.6 -> 0.9.7 - Fix Miri error when `-Zmiri-check-number-validity` is enabled. (#779) - crossbeam-queue 0.3.3 -> 0.3.4 - Implement `IntoIterator` for `ArrayQueue` and `SegQueue`. (#772) - crossbeam-utils 0.8.6 -> 0.8.7 - Add `AtomicCell<i*,u*>::{fetch_max,fetch_min}`. (#785) - Add `AtomicCell<i*,u*,bool>::fetch_nand`. (#785) - Fix unsoundness of `AtomicCell<{i,u}64>` arithmetics on 32-bit targets that support `Atomic{I,U}64` (#781) Co-authored-by: Taiki Endo <[email protected]>
786: Prepare for the next release r=taiki-e a=taiki-e - crossbeam-epoch 0.9.6 -> 0.9.7 - Fix Miri error when `-Zmiri-check-number-validity` is enabled. (#779) - crossbeam-queue 0.3.3 -> 0.3.4 - Implement `IntoIterator` for `ArrayQueue` and `SegQueue`. (#772) - crossbeam-utils 0.8.6 -> 0.8.7 - Add `AtomicCell<{i*,u*}>::{fetch_max,fetch_min}`. (#785) - Add `AtomicCell<{i*,u*,bool}>::fetch_nand`. (#785) - Fix unsoundness of `AtomicCell<{i,u}64>` arithmetics on 32-bit targets that support `Atomic{I,U}64` (#781) Co-authored-by: Taiki Endo <[email protected]>
|
Were the previous releases yanked because of this? It'd be good to note that in the |
|
Originally I was going to write a security advisory on this, but I was busy with work and it got delayed. (I requested CVE today, so it should be published in the next few days) That said, I agree that mentioning the yanked version is a good idea (I usually do it on my projects), so I did that in #788. |
|
Advisory published as GHSA-qc84-gqf4-9926. |
Resolves vulnerability in crossbeam-util. See crossbeam-rs/crossbeam#781 for details. ## Azure IoT Edge PR checklist:
… versions (#6135) crossbeam-utils recently patched an unsoundness bug in `AtomicCell` arithmetic: crossbeam-rs/crossbeam#781. However, this patch was not backported to the older versions required by tokio 0.1 and rayon. This PR updates tokio and rayon to the latest available versions to unify our crossbeam dependencies, in particular unifying crossbeam-util to version 0.7.2. In the process, we can verify that we are not affected by the unsoundness bug by attempting a build with crossbeam-util patched to remove AtomicCell arithmetic. ## Azure IoT Edge PR checklist: This checklist is used to make sure that common guidelines for a pull request are followed. ### General Guidelines and Best Practices - [x] I have read the [contribution guidelines](https://github.com/azure/iotedge#contributing). - [x] Title of the pull request is clear and informative. - [x] Description of the pull request includes a concise summary of the enhancement or bug fix. ### Testing Guidelines - [ ] Pull request includes test coverage for the included changes. - Description of the pull request includes - [ ] concise summary of tests added/modified - [x] local testing done.
… versions (#6136) crossbeam-utils recently patched an unsoundness bug in `AtomicCell` arithmetic: crossbeam-rs/crossbeam#781. However, this patch was not backported to the older versions required by tokio 0.1 and rayon. This PR updates tokio and rayon to the latest available versions, allowing some dependencies to upgrade to a safe crossbeam version. However, tokio still remains on a vulnerable version, so manual verification with a patched build was still required to determine that are not affected by the bug. The notary module had to be modified to remove the `tokio-process` dependency due to the latter's reliance on crossbeam-utils 0.6 (through crossbeam-queue). notary now uses `tokio_threadpool::blocking`. ## Azure IoT Edge PR checklist: This checklist is used to make sure that common guidelines for a pull request are followed. ### General Guidelines and Best Practices - [x] I have read the [contribution guidelines](https://github.com/azure/iotedge#contributing). - [x] Title of the pull request is clear and informative. - [x] Description of the pull request includes a concise summary of the enhancement or bug fix. ### Testing Guidelines - [ ] Pull request includes test coverage for the included changes. - Description of the pull request includes - [ ] concise summary of tests added/modified - [x] local testing done.
|
Hi! Is there a reason why the 0.7.* versions haven't been yanked? I thought it was because they weren't affected by the issue but looking a bit more closely to the changelog for 0.8.0 I don't see why it would be affected and not the 0.7.* versions. When browsing the reverse-dependency list on crates.io, there are still quite a few crates that specify a ^0.7.0 dependency. Rust 1.58.1, for instance, had both 0.8.5 and 0.7.2 in its vendored dependency tree. |
As "Affected versions" in the advisory says, 0.7.x releases are also affected. However, in 0.7.0 and older releases, the affected functionality requires the nightly feature. So the only release that is not yanked and still considered affected is 0.7.2. For the same reason as #749 (comment), we no longer maintain 0.7.x releases. So no backport to 0.7.x has been made. However, if someone sends a backport to the 0.7 branch and also fixes the CI-related issues (which we expect will probably occur), then we can accept it and release a new 0.7.x release.
As far as I know, many of them are crates that are not maintained, or use crossbeam-utils as a dev-dependency.
That has already been fixed: rust-lang/rust@f3b8812 |
|
Quoting Taiki Endo (2022-03-15 18:11:39)
> When browsing the reverse-dependency list on crates.io, there are still quite a few crates that specify a ^0.7.0 dependency.
As far as I know, many of them are crates that are not maintained, or use crossbeam-utils as a dev-dependency.
> Rust 1.58.1, for instance, had both 0.8.5 and 0.7.2 in its vendored dependency tree.
That has already been fixed: rust-lang/rust@f3b8812
I fear I didn't make my point clearly. Indeed, I'd expect maintained
projects to update the dependency on their main branch, as this falls
under the typical maintenance tasks. However, given that this is a crate
that usually sits rather deep in the dependency tree of any project. I
pointed to rustc because it is a well maintained project, and it still
had an outdated dependency to this crate.
I'm not asking for a 0.7.3 version with the fix (although if you
insisted I wouldn't get in your way ;-) ), but I feel like the 0.7.2
should have been yanked as well, so that people that are indirect
consumers lagging a bit behind would have the yanked warning.
|
Unfortunately, yanking does not actually work that way. |
…re#6137) Resolves vulnerability in crossbeam-util. See crossbeam-rs/crossbeam#781 for details. ## Azure IoT Edge PR checklist:
References: crossbeam-rs/crossbeam#781 Signed-off-by: Peng Tao <[email protected]>
Updates crossbeam-utils to 0.8.8 to fix crossbeam-rs/crossbeam#781
…-utils
Specifically, we still rely on crossbeam-utils v0.7.2, which has a known vulnerability fixed in v0.8.7
It does not seem worth putting more effort into this at this time for two reasons:
* Using `rote` does not involve connecting to the internet.
* The vulnerability only affects 32-bit targets according to crossbeam-rs/crossbeam#781 . I'm not running `rote` on any of those at the moment, anyway.
If `rusttype` releases the fixed version to `crates.io` then running `cargo update` will fix it for me, so I plan to wait until some time after that is released to address this.
Updates crossbeam-channel to a newer version that doesn't rely on a buggy version of crossbeam-utils (crossbeam-rs/crossbeam#781)
|
Hey @taiki-e could you release the advisory as Public Domain so we can publish this in RustSec ? Or please feel free to send PR to https://github.com/rustsec/advisory-db EDIT: Oh wait there is CVE-2022-23639 - that we can use - perfect. Thanks! |
|
Sigh. I thought those were in the public domain. I re-licensed all advisories in this repository as the public domain. |
The alignment of u64/i64 on a 32-bit target can be smaller than AtomicU64/AtomicI64.
32-bit targets without Atomic*64 (#767) and 64-bit targets are not affected by this issue.