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

Vulnerable to CVE-2022-23639? #162

Closed
yanns opened this issue Jul 7, 2022 · 7 comments
Closed

Vulnerable to CVE-2022-23639? #162

yanns opened this issue Jul 7, 2022 · 7 comments
Assignees
Labels
security Security related

Comments

@yanns
Copy link

yanns commented Jul 7, 2022

I'm wondering if moka is vulnerable to GHSA-qc84-gqf4-9926 (crossbeam-rs/crossbeam#781)

Dependency tree:

moka v0.8.6
├── crossbeam-epoch v0.8.2
│   ├── crossbeam-utils v0.7.2

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.

@tatsuya6502
Copy link
Member

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 Cargo.toml in their GitHub repository.

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)


The following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)

  • armv7-apple-ios (tier 3)
  • armv7s-apple-ios (tier 3)
  • i386-apple-ios (tier 3)
  • i586-unknown-linux-gnu
  • i586-unknown-linux-musl
  • i686-apple-darwin (tier 3)
  • i686-linux-android
  • i686-unknown-freebsd
  • i686-unknown-haiku (tier 3)
  • i686-unknown-linux-gnu
  • i686-unknown-linux-musl
  • i686-unknown-netbsd (tier 3)
  • i686-unknown-openbsd (tier 3)
  • i686-wrs-vxworks (tier 3)

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.

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.

@tatsuya6502 tatsuya6502 pinned this issue Jul 7, 2022
@tatsuya6502 tatsuya6502 self-assigned this Jul 7, 2022
@tatsuya6502
Copy link
Member

tatsuya6502 commented Jul 7, 2022

I'm wondering if moka is vulnerable to GHSA-qc84-gqf4-9926 (crossbeam-rs/crossbeam#781)

Apparently not.

GHSA-qc84-gqf4-9926 says the followings:

Crates using fetch_* methods with AtomicCell<{i,u}64> are affected by this issue.

I got the source code of crossbeam-utils v0.7.2 and removed AtomicCell from it. I verified that crossbeam-epoch v0.8.2 still compiles, so it does not use AtomicCell.

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 crosbeam-epoch@0.8.2

$ 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 ./src/main.rs and add the following line:

use crossbeam_epoch::{Atomic, CompareAndSetError, Guard, Owned, Shared};

Edit ./Cargo.toml and modify the following line:

[dependencies]
crossbeam-epoch = { path = "./crossbeam-epoch" }  # Modify this line.

Edit ./crossbeam-epoch/Cargo.toml and modify the following line:

[dependencies.crossbeam-utils]
path = "../crossbeam-utils"     # Modify this line.
default-features = false

Remove crossbeam_util::AtomicCell

$ rm crossbeam-utils/src/atomic/atomic_cell.rs

Edit crossbeam-utils/src/atomic/mod.rs and remove the following lines:

mod atomic_cell; // Remove this line.

pub use self::atomic_cell::AtomicCell; // Remove this line.

Run cargo check and verify it compiles

$ cargo tree
hello-epoch-v082 v0.1.0
└── crossbeam-epoch v0.8.2 (... /crossbeam-epoch)
    ├── cfg-if v0.1.10
    ├── crossbeam-utils v0.7.2 (... /crossbeam-utils)

$ cargo check; echo $?
...
    Finished dev [unoptimized + debuginfo] target(s) in 3.63s
0
$ rg crossbeam_utils crossbeam-epoch/src
crossbeam-epoch/src/default.rs
49:    use crossbeam_utils::thread;

crossbeam-epoch/src/sync/list.rs
301:    use crossbeam_utils::thread;

crossbeam-epoch/src/atomic.rs
11:use crossbeam_utils::atomic::AtomicConsume;

crossbeam-epoch/src/sync/queue.rs
13:use crossbeam_utils::CachePadded;
209:    use crossbeam_utils::thread;

crossbeam-epoch/src/lib.rs
80:        extern crate crossbeam_utils;

crossbeam-epoch/src/collector.rs
111:    use crossbeam_utils::thread;

crossbeam-epoch/src/internal.rs
45:use crossbeam_utils::CachePadded;

@tatsuya6502
Copy link
Member

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).

@yanns
Copy link
Author

yanns commented Jul 8, 2022

Thanks for the check, good to know that moka is not vulnerable! 💯

@tatsuya6502 tatsuya6502 added the security Security related label Jul 9, 2022
@TennyZhuang
Copy link

@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!

@tatsuya6502
Copy link
Member

@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.

@tatsuya6502
Copy link
Member

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:

  • Upgrade your dependency to moka v0.9.2.
  • Or, run cargo tree -i crossbeam-utils:v0.7.2 and check if crossbeam-epoch is the only crate depending on. If so, you can safely ignore the alert.
    • moka v0.9.1 or earlier is not vulnerable to CVE-2022-23639, because crossbeam-epoch v0.8.2 does not use the affected functions of crossbeam-utils v0.7.x. This was confirmed with a maintainer of crossbeam crates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security Security related
Projects
None yet
Development

No branches or pull requests

3 participants