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...

Reading uninitialized memory can cause UB (`Deserializer::read_vec`)

Deserializer::readvec created an uninitialized buffer and passes it to a user-provided Read implementation Deserializer.reader.readexact. Passing an uninitialized buffer to an arbitrary Read implementation is currently defined as undefined behavior in Rust. Official documentation for the Read tra...

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...

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...

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...

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...

`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...

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...

`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...

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...

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...

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...

arr! macro erases lifetimes

Affected versions of this crate allowed unsoundly extending lifetimes using arr! macro. This may result in a variety of memory corruption scenarios, most likely use-after-free...

CBox API allows to de-reference raw pointers without `unsafe` code

CBox and CSemiBox are part of the public API of the cbox crate and they allow to create smart pointers from raw pointers and de-reference them without the need of unsafe code...

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...

sigstack allocation bug can cause memory corruption or leak

An embedding using affected versions of lucet-runtime configured to use non-default Wasm globals sizes of more than 4KiB, or compiled in debug mode without optimizations, could leak data from the signal handler stack to guest programs. This can potentially cause data from the embedding host to le...

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...

Unsound `impl Follow for bool`

The implementation of impl Follow for bool allows to reinterpret arbitrary bytes as a bool. In Rust bool has stringent requirements for its in-memory representation. Use of this function allows to violate these requirements and invoke undefined behaviour in safe code...

Incorrect implementation of the Streebog hash functions

Internal update-sigma function was implemented incorrectly and depending on debug-assertions it could've caused an incorrect result or panic for certain inputs...

Flaw in interface may drop uninitialized instance of arbitrary types

Affected versions of this crate would call Vec::setlen on an uninitialized vector with user-provided type parameter, in an interface of the HDR image format decoder. They would then also call other code that could panic before initializing all instances. This could run Drop implementations on...

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...

Bug in SliceDeque::move_head_unchecked allows read of corrupted memory

Affected versions of this crate did not properly update the head and tail of the deque when inserting and removing elements from the front if, before insertion or removal, the tail of the deque was in the mirrored memory region, and if, after insertion or removal, the head of the deque is exactly...

Uncontrolled recursion leads to abort in deserialization

Affected versions of this crate did not prevent deep recursion while deserializing data structures. This allows an attacker to make a YAML file with deeply nested structures that causes an abort while deserializing it. The flaw was corrected by checking the recursion depth. Note: clap 2.33 is not...

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...

Unsoundness in `Error::downcast_mut()`

Affected versions of this crate violate borrow rules, resulting in undefined behavior, when the user adds context to an error via Error::context and then later calls Error::downcastmut on the returned Error. The flaw was corrected in commit 6e8c000 by revising how the mutable reference is...

`pqcrypto-sphincsplus` is unmaintained: upstream PQClean project being archived

This crate provides Rust bindings to SPHINCS+/SLH-DSA FIPS 205 via C implementations from PQClean. The PQClean project is being archived in or after July 2026 see PQClean/PQClean604, after which no further security patches or bug fixes will be applied to the upstream implementations. As a result,...

Wasmtime with Winch compiler backend may allow a sandbox-escaping memory access

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xx5w-cvp6-jv83 For more information see the GitHub-hosted security advisory...

`openssl` `X509VerifyParamRef::set_host` buffer over-read

When this function was passed an empty string, openssl would attempt to call strlen on it, reading arbitrary memory until it reached a NUL byte...

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...

`tauri` filesystem scope partial bypass

A bug identified in this issue allows a partial filesystem scope bypass if glob characters are used within file dialog or drag-and-drop functionalities. This PR fixes the issue by escaping glob characters...

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...

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs: A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event: let sta...

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...

`quinn` invalidly assumes the memory layout of std::net::SocketAddr

The quinn 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...

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...

Reading on uninitialized buffer may cause UB ( `gfx_auxil::read_spirv()` )

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

`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...