1310 matches found
RUSTSEC-2020-0066 crate has been renamed to `sn_bindgen`
This crate has been renamed from safebindgen to snbindgen. The new repository location is:...
RUSTSEC-2020-0081 `mio` invalidly assumes the memory layout of std::net::SocketAddr
The mio crate has assumed std::net::SocketAddrV4 and std::net::SocketAddrV6 have the same memory layout as the system C representation sockaddr. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the...
RUSTSEC-2020-0072 GenericMutexGuard allows data races of non-Sync types across threads
GenericMutexGuard was given the Sync auto trait as long as T is Send due to its contained members. However, since the guard is supposed to represent an acquired lock and allows concurrent access to the underlying data from different threads, it should only be Sync when the underlying data is. Thi...
RUSTSEC-2020-0113 AtomicOption should have Send + Sync bound on its type argument.
In the affected versions of this crate, AtomicOption unconditionally implements Sync. This allows programmers to move non-Sync types across thread boundaries e.g. Rc, Arc, which can lead to data races and undefined behavior. It is also possible to send non-Send types like std::sync::MutexGuard to...
RUSTSEC-2020-0122 beef::Cow lacks a Sync bound on its Send trait allowing for data races
Affected versions of this crate did not have a T: Sync bound in the Send impl for Cow. This allows users to create data races by making Cow contain types that are Send && !Sync like Cell or RefCell. Such data races can lead to memory corruption. The flaw was corrected in commit d1c7658 by adding...
RUSTSEC-2020-0059 MutexGuard::map can cause a data race in safe code
Affected versions of the crate had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U. This could of led to data races in safe Rust code when a closure used in MutexGuard::map returns U that is unrelated to T. The issue was...
RUSTSEC-2020-0055 Please see RUSTSEC-2018-0020
This vulnerability was misfiled under the wrong year and has been withdrawn...
RUSTSEC-2020-0053 dirs is unmaintained, use dirs-next instead
The dirs crate is not maintained any more; use dirs-next instead...
RUSTSEC-2020-0054 directories is unmaintained, use directories-next instead
The directories crate is not maintained any more; use directories-next instead...
RUSTSEC-2020-0058 crate has been renamed to `cipher`
This crate has been renamed from stream-cipher to cipher. The new repository location is at:...
RUSTSEC-2020-0057 crate has been renamed to `cipher`
This crate has been renamed from block-cipher to cipher. The new repository location is at:...
RUSTSEC-2020-0051 Obsolete versions of the `rustsec` crate do not support the new V3 advisory format
If you are seeing this message, you are running an obsolete version of cargo-audit which does not support the new V3 advisory format. These versions are end-of-life. This advisory is a notice that that it will soon be unable to parse the advisory database. Please upgrade cargo-audit to a newer...
RUSTSEC-2020-0050 VecCopy allows misaligned access to elements
VecCopy::data is created as a Vec of u8 but can be used to store and retrieve elements of different types leading to misaligned access. The issue was resolved in v0.5.0 by replacing data being stored by Vec with a custom managed pointer. Elements are now stored and retrieved using types with prop...
RUSTSEC-2020-0047 array_queue pop_back() may cause a use-after-free
arrayqueue implements a circular queue that wraps around an array. However, it fails to properly index into the array in the popback function allowing the reading of previously dropped or uninitialized memory...
RUSTSEC-2020-0043 Insufficient size checks in outgoing buffer in ws allows remote attacker to run the process out of memory
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 t...
RUSTSEC-2020-0042 Missing check in ArrayVec leads to out-of-bounds write.
ArrayVec::insert allows insertion of an element into the array object into the specified index. Due to a missing check on the upperbound of this index, it is possible to write out of bounds...
RUSTSEC-2020-0044 Unsafe Send implementation in Atom allows data races
The atom crate contains a security issue revolving around its implementation of the Send trait. It incorrectly allows any arbitrary type to be sent across threads potentially leading to use-after-free issues through memory races...
RUSTSEC-2020-0041 Multiple soundness issues in Chunk and InlineArray
Chunk: Array size is not checked when constructed with unit and pair. Array size is not checked when constructed with From. Clone and insertfrom are not panic-safe; A panicking iterator causes memory safety issues with them. InlineArray: Generates unaligned references for types with a large...
RUSTSEC-2020-0166 personnummer Input validation error
Swedish personal identity is in the form of YYMMDD-XXXX An issue arises from the regular expression allowing the first three digits in the last four digits of the personnummer to be 000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure...
RUSTSEC-2020-0060 futures_task::waker may cause a use-after-free if used on a type that isn't 'static
Affected versions of the crate did not properly implement a 'static lifetime bound on the waker function. This resulted in a use-after-free if Waker::wake is called after original data had been dropped. The flaw was corrected by adding 'static lifetime bound to the data waker takes...
RUSTSEC-2020-0039 `index()` allows out-of-bound read and `remove()` has off-by-one error
Slab::index does not perform the boundary checking, which leads to out-of-bound read access. Slab::remove copies an element from an invalid address due to off-by-one error, resulting in memory leakage and uninitialized memory drop...
RUSTSEC-2020-0040 Obstack generates unaligned references
Obstack generates unaligned references for types that require a large alignment...
RUSTSEC-2020-0038 Memory safety issues in `compact::Vec`
compact::Vec contains multiple memory safety issues. 1. It mishandles large capacity and causes out-of-bound access in 32-bit / allocator layout mismatch in 64-bit. 2. remove is not panic-safe and causes double-free when an index larger than the length is provided...
RUSTSEC-2020-0037 Misbehaving `HandleLike` implementation can lead to memory safety violation
Unsafe code in ObjectPool has time-of-check to time-of-use TOCTOU bug that can eventually lead to a memory safety violation. ObjectPool and HandlePool implicitly assumes that HandleLike trait methods are pure, i.e., they always return the same value. However, this assumption is unsound since...
RUSTSEC-2020-0164 `cell-project` used incorrect variance when projecting through `&Cell<T>`
Overview The issue lies in the implementation of the cellproject macro which used field as const instead of field as mut . The problem being that const T is covariant in T while mut T is invariant in T. Keep in mind that &Cell is invariant in T, so casting to const T relaxed the variance, and lea...
RUSTSEC-2020-0034 Multiple security issues including data race, buffer overflow, and uninitialized memory drop
arr crate contains multiple security issues. Specifically, 1. It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary. 2. Index and IndexMut implementation does not check the array bound. 3. Array::newfromtemplate drops uninitialized memo...
RUSTSEC-2020-0033 Matrix::new() drops uninitialized memory
Matrix::new internally calls Matrix::fillwith which uses ptr = value pattern to initialize the buffer. This pattern assumes that there is an initialized struct at the address and drops it, which results in dropping of uninitialized struct...
RUSTSEC-2020-0035 Chunk API does not respect align requirement
Chunk API does not respect the align requirement of types. Unaligned reference can be created with the API, which is an undefined behavior...
RUSTSEC-2020-0032 StrcCtx deallocates a memory region that it doesn't own
StrcCtx deallocate a memory region that it doesn't own when StrcCtx is created without using StrcCtx::new. This can introduce memory safety issues such as double-free and use-after-free to client programs...
RUSTSEC-2020-0030 Missing sanitization in mozwire allows local file overwrite of files ending in .conf
The client software downloaded a list of servers from mozilla's servers and created local files named after the hostname field in the json document. No verification of the content of the string was made, and it could therefore have included '../' leading to path traversal. This allows an attacker...
RUSTSEC-2020-0168 mach is unmaintained
Last release was almost 4 years ago. Maintainers seem to be completely unreachable. Possible Alternatives These may or may not be suitable alternatives and have not been vetted in any way; - mach2 - direct fork...
RUSTSEC-2020-0024 Improper uniqueness verification of signature threshold
The tough library, prior to 0.7.1, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures. It allows someone with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum...
RUSTSEC-2020-0165 mozjpeg DecompressScanlines::read_scanlines is Unsound
This issue and vector is similar to RUSTSEC-2020-0029 of rgb crate which mozjpeg depends on. Affected versions of mozjpeg crate allow creating instances of any type T from bytes, and do not correctly constrain T to the types for which it is safe to do so. Examples of safety violation possible for...
RUSTSEC-2020-0022 Ozone contains several memory safety issues
Ozone contains several memory safety issues including out-of-bound access and dropping of uninitialized memory...
RUSTSEC-2020-0052 Undefined Behavior in bounded channel
The affected version of this crate's the bounded channel incorrectly assumes that Vec::fromiter has allocated capacity that same as the number of iterator elements. Vec::fromiter does not actually guarantee that and may allocate extra memory. The destructor of the bounded channel reconstructs Vec...
RUSTSEC-2020-0026 linked-hash-map creates uninitialized NonNull pointer
Affected versions of this crate called mem::uninitialized to create a NonNull, which is undefined behavior. The flaw was corrected by avoiding the use of mem::uninitialized...
RUSTSEC-2020-0167 `pnet_packet` buffer overrun in `set_payload` setters
As indicated by this issue, a buffer overrun is possible in the setpayload setter of the various mutable "Packet" struct setters. The offending setpayload functions were defined within the struct impl blocks in earlier versions of the package, and later by the packet macro. Fixed in the packet...
RUSTSEC-2020-0031 HTTP Request smuggling through malformed Transfer Encoding headers
HTTP pipelining issues and request smuggling attacks are possible due to incorrect Transfer encoding header parsing. It is possible conduct HTTP request smuggling attacks CL:TE/TE:TE by sending invalid Transfer Encoding headers. By manipulating the HTTP response the attacker could poison a...
RUSTSEC-2020-0029 Allows viewing and modifying arbitrary structs as bytes
Affected versions of rgb crate allow viewing and modifying data of any type T wrapped in RGB as bytes, and do not correctly constrain RGB and other wrapper structures to the types for which it is safe to do so. Safety violation possible for a type wrapped in RGB and similar wrapper structures: If...
RUSTSEC-2020-0157 Improper Synchronization and Race Condition in vm-memory
rust-vmm vm-memory before 0.1.1 and 0.2.x before 0.2.1 allows attackers to cause a denial of service loss of IP networking because readobj and writeobj do not properly access memory. This affects aarch64 with musl or glibc and x8664 with musl...
RUSTSEC-2020-0027 traitobject assumes the layout of fat pointers
This crate gets the data pointer from fat pointers assuming that the first element in a fat pointer is the data pointer. This is currently true, but it may change in a future Rust version, leading to memory corruption. This has been fixed in the master branch of the crate, but is has not been...
RUSTSEC-2020-0100 Double free when calling `sys_info::disk_info` from multiple threads
Affected versions of sys-info use a static, global, list to store temporary disk information while running. The function that cleans up this list, DFCleanup, assumes a single threaded environment and will try to free the same memory twice in a multithreaded environment. This results in consistent...
RUSTSEC-2020-0017 Use after free in ArcIntern::drop
ArcIntern::drop has a race condition where it can release memory which is about to get another user. The new user will get a reference to freed memory. This was fixed by serializing access to an interned object while it is being deallocated. Versions prior to 0.3.12 used stronger locking which...
RUSTSEC-2020-0028 `LocalRequest::clone` creates multiple mutable references to the same object
The affected version of rocket contains a Clone trait implementation of LocalRequest that reuses the pointer to inner Request object. This causes data race in rare combinations of APIs if the original and the cloned objects are modified at the same time...
RUSTSEC-2020-0018 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:...
RUSTSEC-2020-0019 tokio-rustls reads may cause excessive memory usage
tokio-rustls does not call processnewpackets immediately after read, so the expected termination condition wantsread always returns true. As long as new incoming data arrives faster than it is processed and the reader does not return pending, data will be buffered. This may cause DoS...
RUSTSEC-2020-0021 rio allows a use-after-free buffer access when a future is leaked
When a rio::Completion is leaked, its drop code will not run. The drop code is responsible for waiting until the kernel completes the I/O operation into, or out of, the buffer borrowed by rio::Completion. Leaking the struct will allow one to access and/or drop the buffer, which can lead to a...
RUSTSEC-2020-0161 `array!` macro is unsound in presence of traits that implement methods it calls internally
Affected versions of this crate called some methods using auto-ref. The affected code looked like this. rust let mut arr = $crate::core::mem::MaybeUninit::uninit; let mut vec = $crate::ArrayVec::::newarr.asmutptr as mut T; In this case, the problem is that asmutptr is a method of &mut MaybeUninit...