1310 matches found
RUSTSEC-2020-0083 crate has been superseded by `sn_client`
This crate has been superseded by snclient. The new repository location is:...
RUSTSEC-2020-0082 ordered_float:NotNan may contain NaN after panic in assignment operators
After using an assignment operators such as NotNan::addassign, NotNan::mulassign, etc., it was possible for the resulting NotNan value to contain a NaN. This could cause undefined behavior in safe code, because the safe NotNan::cmp method contains internal unsafe code that assumes the value is...
RUSTSEC-2020-0077 memmap is unmaintained
The author of the memmap crate is unresponsive. Maintained alternatives: - memmap2...
RUSTSEC-2020-0094 Unsound: can make `ARefss` contain a !Send, !Sync object.
ARefss is a type that is assumed to contain objects that are Send + Sync. In the affected versions of this crate, Send/Sync traits are unconditionally implemented for ARefss. By using the ARefss::map API, we can insert a !Send or !Sync object into ARefss. After that, it is possible to create a da...
RUSTSEC-2020-0142 Send bound needed on T (for Send impl of `Bucket2`)
Affected versions of this crate unconditionally implements Send for Bucket2. This allows sending non-Send types to other threads. This can lead to data races when non Send types like Cell or Rc are contained inside Bucket2 and sent across thread boundaries. The data races can potentially lead to...
RUSTSEC-2020-0088 MPMCConsumer/Producer allows sending non-Send type across threads
Affected versions of this crate unconditionally implemented Sync and Send traits for MPMCConsumer and MPMCProducer types. This allows users to send types that do not implement Send trait across thread boundaries, which can cause a data race. The flaw was corrected in the 2.0.1 release by adding T...
RUSTSEC-2020-0075 Unexpected panic when decoding tokens
Prior to 0.10.0 it was possible to have both decoding functions panic unexpectedly, by supplying tokens with an incorrect base62 encoding. The documentation stated that an error should have been reported instead...
RUSTSEC-2020-0074 Reference counting error in `From<Py<T>>`
A bug in From would lead to an extra reference count decrement, often leading to use-after-free issues...
RUSTSEC-2020-0117 QueueSender<T>/QueueReceiver<T>: Send/Sync impls need `T: Send`
Affected versions of this crate unconditionally implemented Send/Sync for QueueSender, allowing to send non-Send T to other threads by invoking &QueueSender.send. This fails to prevent users from creating data races by sending types like Rc or Arc to other threads, which can lead to memory...
RUSTSEC-2020-0125 convec::ConVec<T> unconditionally implements Send/Sync
Affected versions of this crate unconditionally implement Send/Sync for ConVec. This allows users to insert T that is not Send or not Sync. This allows users to create data races by using non-Send types like Arc or Rc as T in ConVec. It is also possible to create data races by using types like Ce...
RUSTSEC-2020-0128 Cache<K>: Send/Sync impls needs trait bounds on `K`
Affected versions of this crate unconditionally implement Send/Sync for Cache. This allows users to insert K that is not Send or not Sync. This allows users to create data races by using non-Send types like Arc or Rc as K in Cache. It is also possible to create data races by using types like Cell...
RUSTSEC-2020-0071 Potential segfault in the time crate
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...
RUSTSEC-2020-0119 ReadTicket and WriteTicket should only be sendable when T is Send
Affected versions of this crate unconditionally implemented Send for ReadTicket & WriteTicket. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads as T of ReadTicket/WriteTicket. Such data...
RUSTSEC-2020-0087 TryMutex<T> allows sending non-Send type across threads
Affected versions of this crate unconditionally implemented Sync trait for TryMutex type. This allows users to put non-Send T type in TryMutex and send it to another thread, which can cause a data race. The flaw was corrected in the 0.3.0 release by adding T: Send bound for the Sync trait...
RUSTSEC-2020-0135 Slock<T> allows sending non-Send types across thread boundaries
Slock unconditionally implements Send/Sync. Affected versions of this crate allows sending non-Send types to other threads, which can lead to data races and memory corruption due to the data race...
RUSTSEC-2020-0115 Singleton lacks bounds on Send and Sync.
Singleton is meant to be a static object that can be initialized lazily. In order to satisfy the requirement that static items must implement Sync, Singleton implemented both Sync and Send unconditionally. This allows for a bug where non-Sync types such as Cell can be used in singletons and cause...
RUSTSEC-2020-0151 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...
RUSTSEC-2020-0136 CopyCell lacks bounds on its Send trait allowing for data races
CopyCell is a Cell-like type that is implemented for any type T that is Copyable. It's Send trait has no bounds on the contained type. As not all Copyable types are thread safe, for example non-mutable references implement the Copy trait, it is possible to send references to types with interior...
RUSTSEC-2020-0116 PinSlab<T> and Unordered<T, S> need bounds on their Send/Sync traits
Affected versions of this crate unconditionally implemented Send & Sync for types PinSlab & Unordered. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads. This can result in a data race & memory corruption when types that provide...
RUSTSEC-2020-0126 SyncChannel<T> can move 'T: !Send' to other threads
Affected versions of this crate unconditionally implement Send/Sync for SyncChannel. SyncChannel doesn't provide access to &T but merely serves as a channel that consumes and returns owned T. Users can create UB in safe Rust by sending T: !Send to other threads with SyncChannel::send/recv APIs...
RUSTSEC-2020-0133 Queue<T> should have a Send bound on its Send/Sync traits
Affected versions of this crate unconditionally implements Send/Sync for Queue. This allows 1 creating data races to a T: !Sync and 2 sending T: !Send to other threads, resulting in memory corruption or other undefined behavior...
RUSTSEC-2020-0149 Data race and memory safety issue in `Index`
The appendix crate implements a key-value mapping data structure called Index that is stored on disk. The crate allows for any type to inhabit the generic K and V type parameters and implements Send and Sync for them unconditionally. Using a type that is not marked as Send or Sync with Index can...
RUSTSEC-2020-0131 Send/Sync bound needed on T for Send/Sync impl of RcuCell<T>
Affected versions of this crate unconditionally implement Send/Sync for RcuCell. This allows users to send T: !Send to other threads while T enclosed within RcuCell, and allows users to concurrently access T: !Sync by using the APIs of RcuCell that provide access to &T. This can result in memory...
RUSTSEC-2020-0134 `LockWeak<T>` allows to create data race to `T`.
In the affected versions of this crate, LockWeak unconditionally implemented Send with no trait bounds on T. LockWeak doesn't own T and only provides &T. This allows concurrent access to a non-Sync T, which can cause undefined behavior like data races...
RUSTSEC-2020-0080 `miow` invalidly assumes the memory layout of std::net::SocketAddr
The miow 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-0092 Send/Sync bound needed on V in `impl Send/Sync for ARCache<K, V>`
Affected versions of this crate unconditionally implemented Send/Sync traits for ARCache type. This allows users to send/access types that do not implement Send/Sync, which can cause a data race. The flaw was corrected in the 0.2.6 release by adding bounds K: Send + Sync & V: Send + Sync to...
RUSTSEC-2020-0130 Bunch<T> unconditionally implements Send/Sync
Affected versions of this crate unconditionally implements Send/Sync for Bunch. This allows users to insert T: !Sync to Bunch. It is possible to create a data race to a T: !Sync by invoking the Bunch::get API which returns &T from multiple threads. It is also possible to send T: !Send to other...
RUSTSEC-2020-0073 Mutable reference with immutable provenance
A mutable reference to a struct was constructed by dereferencing a pointer obtained from slice::asptr. Instead, slice::asmutptr should have been called on the mutable slice argument. The former performs an implicit reborrow as an immutable shared reference which does not allow writing through the...
RUSTSEC-2020-0069 Argument injection in sendmail transport
Affected versions of lettre allowed argument injection to the sendmail command. It was possible, using forged to addresses, to pass arbitrary arguments to the sendmail executable. Depending on the implementation original sendmail, postfix, exim, etc. it could be possible in some cases to write...
RUSTSEC-2020-0140 `Shared` can cause a data race
Shared data structure in model crate implements Send and Sync traits regardless of the inner type. This allows safe Rust code to trigger a data race, which is undefined behavior in Rust. Users are advised to treat Shared as an unsafe type. It should not be used outside of the testing context, and...
RUSTSEC-2020-0137 AtomicBox<T> lacks bound on its Send and Sync traits allowing data races
AtomicBox is a Box type designed to be used across threads, however, it implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption...
RUSTSEC-2020-0138 ReaderResult should be bounded by Sync
Affected versions of this crate implements Sync for ReaderResult with the trait bound T: Send, E: Send. Since matching on the public enum ReaderResult provides access to &T & &E, allowing data race to a non-Sync type T or E. This can result in a memory corruption when multiple threads concurrentl...
RUSTSEC-2020-0107 hashconsing's HConsed lacks Send/Sync bound for its Send/Sync trait.
Affected versions of hashconsing implements Send/Sync for its HConsed 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...
RUSTSEC-2020-0102 LateStatic has incorrect Sync bound
Affected versions of this crate implemented Sync for LateStatic with T: Send, so that it is possible to create a data race to a type T: Send + !Sync e.g. Cell. This can result in a memory corruption or other kinds of undefined behavior. The flaw was corrected in commit 11f396c by replacing the T:...
RUSTSEC-2020-0159 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...
RUSTSEC-2020-0111 may_queue's Queue lacks Send/Sync bound for its Send/Sync trait.
Affected versions of mayqueue 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...
RUSTSEC-2020-0121 AtomicBox<T> implements Send/Sync for any `T: Sized`
Affected versions of this crate implements Send/Sync for AtomicBox without requiring T: Send/T: Sync. This allows to create data races to T: !Sync and send T: !Send to another thread. Such behavior breaks the compile-time thread safety guarantees of Rust, and allows users to incur undefined...
RUSTSEC-2020-0120 `Decoder<R>` can carry `R: !Send` to other threads
Affected versions of this crate implements Send for Decoder for any R: Read. This allows Decoder to contain R: !Send and carry move it to another thread. This can result in undefined behavior such as memory corruption from data race on R, or dropping R = MutexGuard from a thread that didn't lock...
RUSTSEC-2020-0096 TreeFocus lacks bounds on its Send and Sync traits
Affected versions of im contains TreeFocus that unconditionally implements Send and Sync. This allows a data race in safe Rust code if TreeFocus is extracted from Focus type. Typical users that only use Focus type are not affected...
RUSTSEC-2020-0068 Unexpected panic in multihash `from_slice` parsing code
In versions prior 0.11.3 it's possible to make fromslice panic by feeding it certain malformed input. It's never documented that fromslice and frombytes which wraps it can panic, and its' return type Result suggests otherwise. In practice, fromslice/frombytes is frequently used in networking code...
RUSTSEC-2020-0070 Some lock_api lock guard objects can cause data races
Affected versions of lockapi had unsound implementations of the Send or Sync traits for some guard objects, namely: MappedMutexGuard MappedRwLockReadGuard MappedRwLockWriteGuard RwLockReadGuard RwLockWriteGuard These guards could allow data races through types that are not safe to Send across...
RUSTSEC-2020-0078 `net2` invalidly assumes the memory layout of std::net::SocketAddr
The net2 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-0079 `socket2` invalidly assumes the memory layout of std::net::SocketAddr
The socket2 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-0163 `term_size` is unmaintained; use `terminal_size` instead
The termsize crate is no longer maintained. Consider using terminalsize instead...
RUSTSEC-2020-0076 crate has been renamed to `sn_routing`
This crate has been renamed from routing to snrouting. The new repository location is:...
RUSTSEC-2020-0065 crate has been renamed to `sn_fake_clock`
This crate has been renamed from fakeclock to snfakeclock. The new repository location is:...
RUSTSEC-2020-0067 crate has been renamed to `qp2p`
This crate has been renamed from quic-p2p to qp2p. The new repository location is:...
RUSTSEC-2020-0064 crate has been renamed to `sn_ffi_utils`
This crate has been renamed from ffiutils to snffiutils. The new repository location is:...
RUSTSEC-2020-0145 Use-after-free when cloning a partially consumed `Vec` iterator
The IntoIter Clone implementation clones the whole underlying Vec. If the iterator is partially consumed the consumed items will be copied, thus creating a use-after-free access. A proof of concept is available in the original bug report...