Vulnerable to CVE-2022-23639?

[moka-rs]

Vulnerable to CVE-2022-23639?

[tatsuya6502]

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

[tatsuya6502]

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.

[tatsuya6502]

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.

• #157

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]

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 [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 ./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;

[yanns]

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

[TennyZhuang]

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

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