This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate webrender

Dependencies

(30 total, 19 outdated, 1 insecure, 3 possibly insecure)

CrateRequiredLatestStatus
 app_units^0.70.7.5up to date
 base64^0.100.22.1out of date
 bincode^1.01.3.3up to date
 bitflags^1.02.5.0out of date
 byteorder^1.01.5.0up to date
 cfg-if^0.1.21.0.0out of date
 core-foundation^0.60.9.4out of date
 core-graphics^0.17.10.23.2out of date
 core-text^1320.1.0out of date
 dwrote^0.6.30.11.0out of date
 freetype^0.40.7.2out of date
 fxhash^0.2.10.2.1up to date
 gleam^0.6.80.15.0out of date
 image ⚠️^0.200.25.1out of date
 lazy_static^11.4.0up to date
 libc^0.20.2.154up to date
 log^0.40.4.21up to date
 num-traits^0.20.2.18up to date
 plane-split^0.13.30.18.0out of date
 png^0.120.17.13out of date
 rayon^11.10.0up to date
 ron^0.1.70.8.1out of date
 serde^1.01.0.200up to date
 serde_json^1.01.0.116up to date
 sha2^0.80.10.8out of date
 smallvec ⚠️^0.61.13.2out of date
 thread_profiler^0.1.10.3.0out of date
 time ⚠️^0.10.3.36out of date
 webrender_api^0.58.00.61.0out of date
 ws ⚠️^0.7.30.9.2insecure

Dev dependencies

(2 total, 2 outdated)

CrateRequiredLatestStatus
 mozangle^0.10.5.1out of date
 rand^0.40.8.5out of date

Security Vulnerabilities

image: Flaw in interface may drop uninitialized instance of arbitrary types

RUSTSEC-2019-0014

Affected versions of this crate would call Vec::set_len on an uninitialized vector with user-provided type parameter, in an interface of the HDR image format decoder. They would then also call other code that could panic before initializing all instances.

This could run Drop implementations on uninitialized types, equivalent to use-after-free, and allow an attacker arbitrary code execution.

Two different fixes were applied. It is possible to conserve the interface by ensuring proper initialization before calling Vec::set_len. Drop is no longer called in case of panic, though.

Starting from version 0.22, a breaking change to the interface requires callers to pre-allocate the output buffer and pass a mutable slice instead, avoiding all unsafe code.

ws: Insufficient size checks in outgoing buffer in ws allows remote attacker to run the process out of memory

RUSTSEC-2020-0043

Affected versions of this crate did not properly check and cap the growth of the outgoing buffer.

This allows a remote attacker to take down the process by growing the buffer of their (single) connection until the process runs out of memory it can allocate and is killed.

The flaw was corrected in the parity-ws fork (>=0.10.0) by disconnecting a client when the buffer runs full.

time: Potential segfault in the time crate

RUSTSEC-2020-0071

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

  • time::UtcOffset::local_offset_at
  • time::UtcOffset::try_local_offset_at
  • time::UtcOffset::current_local_offset
  • time::UtcOffset::try_current_local_offset
  • time::OffsetDateTime::now_local
  • time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

  • at
  • at_utc
  • now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

A possible workaround for crates affected through the transitive dependency in chrono, is to avoid using the default oldtime feature dependency of the chrono crate by disabling its default-features and manually specifying the required features instead.

Examples:

Cargo.toml:

chrono = { version = "0.4", default-features = false, features = ["serde"] }
chrono = { version = "0.4.22", default-features = false, features = ["clock"] }

Commandline:

cargo add chrono --no-default-features -F clock

Sources:

smallvec: Buffer overflow in SmallVec::insert_many

RUSTSEC-2021-0003

A bug in the SmallVec::insert_many method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.

This bug was only triggered if the iterator passed to insert_many yielded more items than the lower bound returned from its size_hint method.

The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of insert_many to use less unsafe code, so it is easier to verify its correctness.

Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.