Deps.rs

tokio-threadpool 0.1.11

[![dependency status](https://deps.rs/crate/tokio-threadpool/0.1.11/status.svg)](https://deps.rs/crate/tokio-threadpool/0.1.11)

This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate tokio-threadpool

Dependencies

(10 total, 6 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 crossbeam^0.6.00.8.4out of date
 crossbeam-channel^0.3.30.5.12out of date
 crossbeam-deque ⚠️^0.6.10.8.5out of date
 crossbeam-utils^0.6.20.8.19out of date
 futures^0.1.190.3.30out of date
 log^0.40.4.21up to date
 num_cpus^1.21.16.0up to date
 rand^0.60.8.5out of date
 slab^0.4.10.4.9up to date
 tokio-executor^0.1.20.1.10up to date

Dev dependencies

(3 total, 1 outdated)

CrateRequiredLatestStatus
 env_logger^0.50.11.3out of date
 futures-cpupool^0.1.70.1.8up to date
 threadpool^1.7.11.8.1up to date

Security Vulnerabilities

crossbeam-deque: Data race in crossbeam-deque

RUSTSEC-2021-0093

In the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug.

Crates using Stealer::steal, Stealer::steal_batch, or Stealer::steal_batch_and_pop are affected by this issue.

Credits to @kmaork for discovering, reporting and fixing the bug.