dlunch / ffxivtools Goto Github PK

Generators can cause data races if non-Send types are used in their generator functions

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.

See advisory page for additional details.

Out-of-bounds write in nix::unistd::getgrouplist

On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the reqested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.

See advisory page for additional details.

stdweb is unmaintained

The author of the stdweb crate is unresponsive.

Maintained alternatives:

• wasm-bindgen
• js-sys
• web-sys

See advisory page for additional details.

spin is no longer actively maintained

The author of the spin crate does not have time or interest to maintain it.

Consider the following alternatives (both of which support no_std):

• conquer-once
• lock_api (a subproject of parking_lot)
  • spinning_top spinlock crate built on lock_api

See advisory page for additional details.

memmap is unmaintained

The author of the memmap crate is unresponsive.

Maintained alternatives:

• mapr
• memmap2

See advisory page for additional details.

crate has been renamed to block-cipher

This crate has been renamed from block-cipher-trait to block-cipher.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/block-cipher>

See advisory page for additional details.

anymap is unmaintained.

The anymap crate does not appear to be maintained, and the most recent
published version 0.12.1 includes a soundness bug. This has been
fixed a few years ago, but
was never released.

See advisory page for additional details.

stb_truetype crate has been deprecated; use ttf-parser instead

This crate was maintained for use in rusttype which has switched to use ttf-parser

See advisory page for additional details.

xml-rs is Unmaintained

xml-rs is a XML parser has open issues around parsing including integer
overflows / panics that may or may not be an issue with untrusted data.

Together with these open issues with Unmaintained status xml-rs
may or may not be suited to parse untrusted data.

Alternatives

• quick-xml

See advisory page for additional details.

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

VecStorage Deserialize Allows Violation of Length Invariant

The Deserialize implementation for VecStorage did not maintain the invariant that the number of elements must equal nrows * ncols. Deserialization of specially crafted inputs could allow memory access beyond allocation of the vector.

This flaw was introduced in v0.11.0 (086e6e) due to the addition of an automatically derived implementation of Deserialize for MatrixVec. MatrixVec was later renamed to VecStorage in v0.16.13 (0f66403) and continued to use the automatically derived implementation of Deserialize.

This flaw was corrected in commit 5bff536 by returning an error during deserialization if the number of elements does not exactly match the expected size.

See advisory page for additional details.

Large cookie Max-Age values can cause a denial of service

Affected versions of this crate use the time crate and the method
Duration::seconds to parse the Max-Age duration cookie setting. This method
will panic if the value is greater than 2^64/1000 and less than or equal to
2^64, which can result in denial of service for a client or server.

This flaw was corrected by explicitly checking for the Max-Age being in this
integer range and clamping the value to the maximum duration value.

See advisory page for additional details.

Out-of-bounds write in nix::unistd::getgrouplist

On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the reqested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.

See advisory page for additional details.

see https://github.com/jansol/texpresso

Potential segfault in the time crate

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

No workarounds are known.

See advisory page for additional details.

Potential segfault in localtime_r invocations

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.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.