1119 matches found
UsbContext trait did not require implementers to be Send and Sync.
Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The...
Async-h1 request smuggling possible with long unread bodies
This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications. If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at...
Dangling reference in `access::Map` with Constant
Using the arcswap::access::Map with the Constant test helper or with user-provided implementation of the Access trait could sometimes lead to the map returning dangling references. Replaced by implementation without unsafe, at the cost of added Clone bound on the closure and small penalty on...
nanorand 0.5.0 - RNGs failed to generate properly for non-64-bit numbers
In versions of nanorand prior to 0.5.1, RandomGen implementations for standard unsigned integers could fail to properly generate numbers, due to using bit-shifting to truncate a 64-bit number, rather than just an as conversion. This often manifested as RNGs returning nothing but 0, including the...
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...
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...
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...
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...
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...
`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...
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...
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...
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...
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...
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...
tiberius is unmaintained
The author of tiberius has archived the GitHub repository and left the following note: I do not have the time to overhaul the library and do not intend to further maintain the 0.3 version relying on the old futures ecosystem. Suggested alternatives are: - odbc - sqlx forthcoming...
bespoke Cell implementation allows obtaining several mutable references to the same data
The custom implementation of a Cell primitive in the affected versions of this crate does not keep track of mutable references to the underlying data. This allows obtaining several mutable references to the same object which may result in arbitrary memory corruption, most likely use-after-free. T...
typemap is Unmaintained
The maintainer seems unreachable. The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust. The last release seems to have been seven years ago. Possible Alternatives The below list has not been vetted in any way and may or may not contain...
Malicious input could cause uninitialized memory to be exposed
Affected versions of Claxon made an invalid assumption about the decode buffer size being a multiple of a value read from the bitstream. This could cause parts of the decode buffer to not be overwritten. If the decode buffer was newly allocated and uninitialized, this uninitialized memory could b...
Possible double free during unwinding in SmallVec::insert_many
If an iterator passed to SmallVec::insertmany panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free a destructor running on two copies of the same value. This is fixed in smallvec 0.6.3 by ensuring that the...
Links in archives can overwrite any existing file
When unpacking a tarball with the unpackin-family of functions it's intended that only files within the specified directory are able to be written. Tarballs with hard links or symlinks, however, can be used to overwrite any file on the filesystem. Tarballs can contain multiple entries for the sam...
headers containing newline characters can split messages
Serializing of headers to the socket did not filter the values for newline bytes \r or \n, which allowed for header values to split a request or response. People would not likely include newlines in the headers in their own applications, so the way for most people to exploit this is if an...
TLS certificate common name validation bypass
The NATS official Rust clients are vulnerable to MitM when using TLS. The common name of the server's TLS certificate is validated against the hostname provided by the server's plaintext INFO message during the initial connection setup phase. A MitM proxy can tamper with the host field's value by...
Unsound API in `secp256k1` allows use-after-free and invalid deallocation from safe code
Because of incorrect bounds on method Secp256k1::preallocatedgennew it was possible to cause use-after-free from safe consumer code. It was also possible to "free" memory not allocated by the appropriate allocator. The method takes a place for storing the context as a mutable reference and return...
matrix-sdk 0.6.0 logs access tokens
When sending Matrix requests using an affected version of matrix-sdk in an application that writes logs using tracing-subscriber in a way that includes fields of tracing spans such as tracingsubscribers default text output from the fmt module, these logs will contain the user's access token...
No default limit put on request bodies
::fromrequest would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large or infinite body your server might run out of memory and crash. This also applies to these extractors which used Bytes::fromrequest internally: -...
json is unmaintained
Last release was almost 3 years ago. The maintainer is unresponsive with outstanding issues. One of the outstanding issues include a possible soundness issue. Possible Alternatives The below list has not been vetted in any way and may or may not contain alternatives; - jzon maintained fork of jso...
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 functi...
vec-const attempts to construct a Vec from a pointer to a const slice
Affected versions of this crate claimed to construct a const Vec with nonzero length and capacity, but that cannot be done because such a Vec requires a pointer from an allocator. The implementation was later changed to just construct a std::borrow::Cow...
Remote memory exhaustion in ckb
In the ckb sync protocol, SyncState maintains a HashMap called 'misbehavior' that keeps a score of a peer's violations of the protocol. This HashMap is keyed to PeerIndex an alias for SessionId, and entries are never removed from it. SessionId is an integer that increases monotonically with every...
libsecp256k1 allows overflowing signatures
libsecp256k1 accepts signatures whose R or S parameter is larger than the secp256k1 curve order, which differs from other implementations. This could lead to invalid signatures being verified. The error is resolved in 0.5.0 by adding a checkoverflow flag...
Flaw in `FieldVar::mul_by_inverse` allows unsound R1CS constraint systems
Versions 0.2.0 to 0.3.0 of ark-r1cs-std did not enforce any constraints in the FieldVar::mulbyinverse method, allowing a malicious prover to produce an unsound proof that passes all verifier checks. This method was used primarily in scalar multiplication for shortweierstrass::ProjectiveVar. This...
'merge_sort::merge()' crashes with double-free for `T: Drop`
In the affected versions of this crate, mergesort::merge wildly duplicates and drops ownership of T without guarding against double-free. Due to such implementation, simply invoking mergesort::merge on Vec can cause double free bugs...
Multiple memory safety issues
Affected versions contain multiple memory safety issues, such as: - Setting a multi label type where an image doesn't exist would lead to a NULL pointer dereference. - Setting a window icon using a non-raster image which FLTK rasterizes lazily would lead to a NULL dereference. - Pixmap constructo...
PartialReader passes uninitialized memory to user-provided Read
Affected versions of this crate passed an uniniitalized buffer to a user-provided Read instance in PartialReader::read. This can result in safe Read implementations reading from the uninitialized buffer leading to undefined behavior. The flaw was fixed in commit 39d62c6 by zero-initializing the...
Deserialization functions pass uninitialized memory to user-provided Read
Affected versions of this crate passed an uninitialized buffer to a user-provided Read instance in: deserializebinary deserializestring deserializeextensionothers deserializestringprimitive This can result in safe Read implementations reading from the uninitialized buffer leading to undefined...
panic safety: double drop or uninitialized drop of T upon panic
Affected versions of this crate did not guard against potential panics that may happen from user-provided functions T::default and T::drop. Panic within T::default leads to dropping uninitialized T, when it is invoked from common::Slice::::new. Panic within T::drop leads to double drop of T, when...
Loading a bgzip block can write out of bounds if size overflows.
Affected versions of bam set the length of an internal buffer using self.compressed.setlenblocksize - HEADERSIZE - MINEXTRASIZE and then wrote into it. While blocksize was constrained to a proper maximum, when it was too small the subtraction could overflow negatively to a large number past the...
XSS in mdBook's search page
This is a cross-post of the official security advisoryml. The official post contains a signed version with our PGP key, as well. ml: https://groups.google.com/g/rustlang-security-announcements/c/3-sO6of29O0 The Rust Security Response Working Group was recently notified of a security issue affecti...
`Read` on uninitialized buffer can cause UB (impl of `ReadKVExt`)
Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory...
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...
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...
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...
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...
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...
`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...
`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...
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...
`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...
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...