-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Vulnerable to CVE-2022-23639? #162
Comments
Hi. Thank you for creating the issue. I noticed that GitHub Dependabot has started to alert about CVE-2022-23639 to everyone who have the affected crossbeam-utils versions in the Let me check whether moka is really affected by it or not. Maybe I will have to talk to the crossbeam team. I will do it in tomorrow morning if necessary. (It is ~2 AM now in my time zone. UTC+0800) Also, I would suggest you to check if your users are likely using the affected platforms below: (Copied from GHSA-qc84-gqf4-9926)
Right. I opened this PR last week. I started to run tests and I hoped it will not make #34 worse. Unfortunately, my initial tests on Linux x86_64 showed that it will make worse; moka with crossbeam-epoch v0.9.9 had 15% more chance to reproduce the issue than moka with crossbeam-epoch v0.8.2. I am planning to repeat the test in this weekend just for sure. |
Apparently not. GHSA-qc84-gqf4-9926 says the followings:
I got the source code of crossbeam-utils v0.7.2 and removed Here is what I did: Create a test package and expand crate sources## Create a test package (project).
$ cargo new hello-epoch082
$ cd $_
## Add crossbeam-epoch v0.8.2 as a dependency.
## Make sure you use Rust 1.62 or newer, whose Cargo has `add` subcommand.
$ cargo add [email protected]
$ cargo tree
hello-epoch-v082 v0.1.0
└── crossbeam-epoch v0.8.2
├── cfg-if v0.1.10
├── crossbeam-utils v0.7.2
│ ├── cfg-if v0.1.10
│ └── lazy_static v1.4.0
│ [build-dependencies]
│ └── autocfg v1.1.0
├── lazy_static v1.4.0
├── maybe-uninit v2.0.0
├── memoffset v0.5.6
│ [build-dependencies]
│ └── autocfg v1.1.0
└── scopeguard v1.1.0
[build-dependencies]
└── autocfg v1.1.0
## Vendor the source files of the dependencies.
$ cargo vendor
$ exa -l vendor/
drwxr-xr-x - tatsuya 8 Jul 06:00 autocfg
drwxr-xr-x - tatsuya 8 Jul 06:00 cfg-if
drwxr-xr-x - tatsuya 8 Jul 06:00 crossbeam-epoch
drwxr-xr-x - tatsuya 8 Jul 06:00 crossbeam-utils
drwxr-xr-x - tatsuya 8 Jul 06:00 lazy_static
drwxr-xr-x - tatsuya 8 Jul 06:00 maybe-uninit
drwxr-xr-x - tatsuya 8 Jul 06:00 memoffset
drwxr-xr-x - tatsuya 8 Jul 06:00 scopeguard
## Move the vendored source files to the package root directory
## so that we can modify them.
$ mv vendor/crossbeam-epoch .
$ mv vendor/crossbeam-utils .
$ rm -rf vendor Edit use crossbeam_epoch::{Atomic, CompareAndSetError, Guard, Owned, Shared}; Edit [dependencies]
crossbeam-epoch = { path = "./crossbeam-epoch" } # Modify this line. Edit [dependencies.crossbeam-utils]
path = "../crossbeam-utils" # Modify this line.
default-features = false Remove
|
To make GitHub Dependabot happy, I am going to talk to the crossbeam team if they could create a new version of crossbeam-epoch v0.8.x that depends on a fixed version of crossbeam-utils (>= v0.8.7). |
Thanks for the check, good to know that moka is not vulnerable! 💯 |
@tatsuya6502 In fact the issue can be closed in the v0.9.2, can you publish the version to crates.io? I see that the version in repo is already bumped. Thank you so much for the fix! |
@TennyZhuang — Yes. I will publish v0.9.2 to crates.io soon. I am currently running a pre-release test. It will be finished in four hours from now. |
Closing this issue as moka v0.9.2 has been published to crates.io. It has the crossbeam-epoch dependency upgraded from v0.8.2 to the latest v0.9.9. If you got a security alert about CVE-2022-23639 for crossbeam-utils when using an earlier version of moka, you can do one of the followings:
|
I'm wondering if moka is vulnerable to GHSA-qc84-gqf4-9926 (crossbeam-rs/crossbeam#781)
Dependency tree:
I could also see that staying with the v0.8.2 is a conscious decision: https://github.com/moka-rs/moka/blob/master/Cargo.toml#L68-L71
In that case, we would need a fix for #34 first.
The text was updated successfully, but these errors were encountered: