Impact

The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.

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:

• time::at_utc
• time::at
• time::now
• time::tzset

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:

• chronotope/chrono#602 (comment)
• vityafx/serde-aux#21

Affected versions of may_queue implements Send/Sync for its Queue type without restricting it to Sendable types and Syncable types.

This allows non-Sync types such as Cell to be shared across threads leading to undefined behavior and memory corruption in concurrent programs.

The Generator type is an iterable which uses a generator function that yields values. In affected versions of the crate, the provided function yielding values had no Send bounds despite the Generator itself implementing Send.

The generator function lacking a Send bound means that types that are dangerous to send across threads such as Rc could be sent as part of a generator, potentially leading to data races.

This flaw was fixed in commit f7d120a3b by enforcing that the generator function be bound by Send.

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.

The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes).