|
|
Search Results
There are 142 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2025-48754 | In the memory_pages crate 0.1.0 for Rust, division by zero can occur. |
| CVE-2025-47270 | nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. The `nimiq-network-libp2p` subcrate of nimiq/core-rs-albatross is vulnerable to a Denial of Service (DoS) attack due to uncontrolled memory allocation. Specifically, the implementation of the `Discovery` network message handling allocates a buffer based on a length value provided by the peer, without enforcing an upper bound. Since this length is a `u32`, a peer can trigger allocations of up to 4 GB, potentially leading to memory exhaustion and node crashes. As Discovery messages are regularly exchanged for peer discovery, this vulnerability can be exploited repeatedly. The patch for this vulnerability is formally released as part of v1.1.0. The patch implements a limit to the discovery message size of 1 MB and also resizes the message buffer size incrementally as the data is read. No known workarounds are available. |
| CVE-2025-46718 | sudo-rs is a memory safe implementation of sudo and su written in Rust. Prior to version 0.2.6, users with limited sudo privileges (e.g. execution of a single command) can list sudo privileges of other users using the `-U` flag. This vulnerability allows users with limited sudo privileges to enumerate the sudoers file, revealing sensitive information about other users' permissions. Attackers can collect information that can be used to more targeted attacks. Systems where users either do not have sudo privileges or have the ability to run all commands as root through sudo (the default configuration on most systems) are not affected by this advisory. Version 0.2.6 fixes the vulnerability. |
| CVE-2025-46717 | sudo-rs is a memory safe implementation of sudo and su written in Rust. Prior to version 0.2.6, users with no (or very limited) sudo privileges can determine whether files exists in folders that they otherwise cannot access using `sudo --list <pathname>`. Users with local access to a machine can discover the existence/non-existence of certain files, revealing potentially sensitive information in the file names. This information can also be used in conjunction with other attacks. Version 0.2.6 fixes the vulnerability. |
| CVE-2025-4574 | In crossbeam-channel rust crate, the internal `Channel` type's `Drop` method has a race condition which could, in some circumstances, lead to a double-free that could result in memory corruption. |
| CVE-2025-24898 | rust-openssl is a set of OpenSSL bindings for the Rust programming language. In affected versions `ssl::select_next_proto` can return a slice pointing into the `server` argument's buffer but with a lifetime bound to the `client` argument. In situations where the `sever` buffer's lifetime is shorter than the `client` buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client. The crate`openssl` version 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers. Users are advised to upgrade. In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. |
| CVE-2024-7884 | When a canister method is called via ic_cdk::call* , a new Future CallFuture is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called CallFutureState. A bug in the polling implementation of the CallFuture allows multiple references to be held for this internal state and not all references were dropped before the Future is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak. Impact Canisters built in Rust with ic_cdk and ic_cdk_timers are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. In the worst case, this could lead to heap memory exhaustion triggered by an attacker. Motoko based canisters are not affected by the bug. PatchesThe patch has been backported to all minor versions between >= 0.8.0, <= 0.15.0. The patched versions available are 0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1 and their previous versions have been yanked. WorkaroundsThere are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of ic_cdk to avoid running out of Wasm heap memory. Upgrading the canisters (without updating `ic_cdk`) also frees the leaked memory but it's only a temporary solution. |
| CVE-2024-43806 | Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using `rustix::fs::Dir` using the `linux_raw` backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the `Dir` iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. `/proc`, `/sys`) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using `rustix::fs::Dir` directly or indirectly (e.g. with the `procfs` crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue. |
| CVE-2024-43783 | The Apollo Router Core is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation 2. Instances of the Apollo Router running versions >=1.21.0 and < 1.52.1 are impacted by a denial of service vulnerability if _all_ of the following are true: 1. The Apollo Router has been configured to support [External Coprocessing](https://www.apollographql.com/docs/router/customizations/coprocessor). 2. The Apollo Router has been configured to send request bodies to coprocessors. This is a non-default configuration and must be configured intentionally by administrators. Instances of the Apollo Router running versions >=1.7.0 and <1.52.1 are impacted by a denial-of-service vulnerability if all of the following are true: 1. Router has been configured to use a custom-developed Native Rust Plugin. 2. The plugin accesses Request.router_request in the RouterService layer. 3. You are accumulating the body from Request.router_request into memory. If using an impacted configuration, the Router will load entire HTTP request bodies into memory without respect to other HTTP request size-limiting configurations like limits.http_max_request_bytes. This can cause the Router to be out-of-memory (OOM) terminated if a sufficiently large request is sent to the Router. By default, the Router sets limits.http_max_request_bytes to 2 MB. If you have an impacted configuration as defined above, please upgrade to at least Apollo Router 1.52.1. If you cannot upgrade, you can mitigate the denial-of-service opportunity impacting External Coprocessors by setting the coprocessor.router.request.body configuration option to false. Please note that changing this configuration option will change the information sent to any coprocessors you have configured and may impact functionality implemented by those coprocessors. If you have developed a Native Rust Plugin and cannot upgrade, you can update your plugin to either not accumulate the request body or enforce a maximum body size limit. You can also mitigate this issue by limiting HTTP body payload sizes prior to the Router (e.g., in a proxy or web application firewall appliance). |
| CVE-2024-43410 | Russh is a Rust SSH client & server library. Allocating an untrusted amount of memory allows any unauthenticated user to OOM a russh server. An SSH packet consists of a 4-byte big-endian length, followed by a byte stream of this length. After parsing and potentially decrypting the 4-byte length, russh allocates enough memory for this bytestream, as a performance optimization to avoid reallocations later. But this length is entirely untrusted and can be set to any value by the client, causing this much memory to be allocated, which will cause the process to OOM within a few such requests. This vulnerability is fixed in 0.44.1. |
| CVE-2024-34063 | vodozemac is an implementation of Olm and Megolm in pure Rust. Versions 0.5.0 and 0.5.1 of vodozemac have degraded secret zeroization capabilities, due to changes in third-party cryptographic dependencies (the Dalek crates), which moved secret zeroization capabilities behind a feature flag and defaulted this feature to off. The degraded zeroization capabilities could result in the production of more memory copies of encryption secrets and secrets could linger in memory longer than necessary. This marginally increases the risk of sensitive data exposure. This issue has been addressed in version 0.6.0 and users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2024-32984 | Yamux is a stream multiplexer over reliable, ordered connections such as TCP/IP. The Rust implementation of the Yamux stream multiplexer uses a vector for pending frames. This vector is not bounded in length. Every time the Yamux protocol requires sending of a new frame, this frame gets appended to this vector. This can be remotely triggered in a number of ways, for example by: 1. Opening a new libp2p Identify stream. This causes the node to send its Identify message. Of course, every other protocol that causes the sending of data also works. The larger the response, the more data is enqueued. 2. Sending a Yamux Ping frame. This causes a Pong frame to be enqueued. Under normal circumstances, this queue of pending frames would be drained once they’re sent out over the network. However, the attacker can use TCP’s receive window mechanism to prevent the victim from sending out any data: By not reading from the TCP connection, the receive window will never be increased, and the victim won’t be able to send out any new data (this is how TCP implements backpressure). Once this happens, Yamux’s queue of pending frames will start growing indefinitely. The queue will only be drained once the underlying TCP connection is closed. An attacker can cause a remote node to run out of memory, which will result in the corresponding process getting terminated by the operating system. |
| CVE-2024-28101 | The Apollo Router is a graph router written in Rust to run a federated supergraph that uses Apollo Federation. Versions 0.9.5 until 1.40.2 are subject to a Denial-of-Service (DoS) type vulnerability. When receiving compressed HTTP payloads, affected versions of the Router evaluate the `limits.http_max_request_bytes` configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded. Router version 1.40.2 has a fix for the vulnerability. Those who are unable to upgrade may be able to implement mitigations at proxies or load balancers positioned in front of their Router fleet (e.g. Nginx, HAProxy, or cloud-native WAF services) by creating limits on HTTP body upload size. |
| CVE-2024-27284 | cassandra-rs is a Cassandra (CQL) driver for Rust. Code that attempts to use an item (e.g., a row) returned by an iterator after the iterator has advanced to the next item will be accessing freed memory and experience undefined behaviour. The problem has been fixed in version 3.0.0. |
| CVE-2023-50711 | vmm-sys-util is a collection of modules that provides helpers and utilities used by multiple rust-vmm components. Starting in version 0.5.0 and prior to version 0.12.0, an issue in the `FamStructWrapper::deserialize` implementation provided by the crate for `vmm_sys_util::fam::FamStructWrapper` can lead to out of bounds memory accesses. The deserialization does not check that the length stored in the header matches the flexible array length. Mismatch in the lengths might allow out of bounds memory access through Rust-safe methods. The issue was corrected in version 0.12.0 by inserting a check that verifies the lengths of compared flexible arrays are equal for any deserialized header and aborting deserialization otherwise. Moreover, the API was changed so that header length can only be modified through Rust-unsafe code. This ensures that users cannot trigger out-of-bounds memory access from Rust-safe code. |
| CVE-2023-41051 | In a typical Virtual Machine Monitor (VMM) there are several components, such as boot loader, virtual device drivers, virtio backend drivers and vhost drivers, that need to access the VM physical memory. The vm-memory rust crate provides a set of traits to decouple VM memory consumers from VM memory providers. An issue was discovered in the default implementations of the `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref}` trait functions, which allows out-of-bounds memory access if the `VolatileMemory::get_slice` function returns a `VolatileSlice` whose length is less than the function’s `count` argument. No implementations of `get_slice` provided in `vm_memory` are affected. Users of custom `VolatileMemory` implementations may be impacted if the custom implementation does not adhere to `get_slice`'s documentation. The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the `VolatileSlice` returned by `get_slice` is of the correct length. Users are advised to upgrade. There are no known workarounds for this issue. |
| CVE-2023-28448 | Versionize is a framework for version tolerant serializion/deserialization of Rust data structures, designed for usecases that need fast deserialization times and minimal size overhead. An issue was discovered in the ‘Versionize::deserialize’ implementation provided by the ‘versionize’ crate for ‘vmm_sys_utils::fam::FamStructWrapper', which can lead to out of bounds memory accesses. The impact started with version 0.1.1. The issue was corrected in version 0.1.10 by inserting a check that verifies, for any deserialized header, the lengths of compared flexible arrays are equal and aborting deserialization otherwise. |
| CVE-2022-46149 | Cap'n Proto is a data interchange format and remote procedure call (RPC) system. Cap'n Proro prior to versions 0.7.1, 0.8.1, 0.9.2, and 0.10.3, as well as versions of Cap'n Proto's Rust implementation prior to 0.13.7, 0.14.11, and 0.15.2 are vulnerable to out-of-bounds read due to logic error handling list-of-list. This issue may lead someone to remotely segfault a peer by sending it a malicious message, if the victim performs certain actions on a list-of-pointer type. Exfiltration of memory is possible if the victim performs additional certain actions on a list-of-pointer type. To be vulnerable, an application must perform a specific sequence of actions, described in the GitHub Security Advisory. The bug is present in inlined code, therefore the fix will require rebuilding dependent applications. Cap'n Proto has C++ fixes available in versions 0.7.1, 0.8.1, 0.9.2, and 0.10.3. The `capnp` Rust crate has fixes available in versions 0.13.7, 0.14.11, and 0.15.2. |
| CVE-2022-39294 | conduit-hyper integrates a conduit application with the hyper server. Prior to version 0.4.2, `conduit-hyper` did not check any limit on a request's length before calling [`hyper::body::to_bytes`](https://docs.rs/hyper/latest/hyper/body/fn.to_bytes.html). An attacker could send a malicious request with an abnormally large `Content-Length`, which could lead to a panic if memory allocation failed for that request. In version 0.4.2, `conduit-hyper` sets an internal limit of 128 MiB per request, otherwise returning status 400 ("Bad Request"). This crate is part of the implementation of Rust's [crates.io](https://crates.io/), but that service is not affected due to its existing cloud infrastructure, which already drops such malicious requests. Even with the new limit in place, `conduit-hyper` is not recommended for production use, nor to directly serve the public Internet. |
| CVE-2022-36124 | It is possible for a Reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue. |
| CVE-2022-35922 | Rust-WebSocket is a WebSocket (RFC6455) library written in Rust. In versions prior to 0.26.5 untrusted websocket connections can cause an out-of-memory (OOM) process abort in a client or a server. The root cause of the issue is during dataframe parsing. Affected versions would allocate a buffer based on the declared dataframe size, which may come from an untrusted source. When `Vec::with_capacity` fails to allocate, the default Rust allocator will abort the current process, killing all threads. This affects only sync (non-Tokio) implementation. Async version also does not limit memory, but does not use `with_capacity`, so DoS can happen only when bytes for oversized dataframe or message actually got delivered by the attacker. The crashes are fixed in version 0.26.5 by imposing default dataframe size limits. Affected users are advised to update to this version. Users unable to upgrade are advised to filter websocket traffic externally or to only accept trusted traffic. |
| CVE-2022-23639 | crossbeam-utils provides atomics, synchronization primitives, scoped threads, and other utilities for concurrent programming in Rust. crossbeam-utils prior to version 0.8.7 incorrectly assumed that the alignment of `{i,u}64` was always the same as `Atomic{I,U}64`. However, the alignment of `{i,u}64` on a 32-bit target can be smaller than `Atomic{I,U}64`. This can cause unaligned memory accesses and data race. Crates using `fetch_*` methods with `AtomicCell<{i,u}64>` are affected by this issue. 32-bit targets without `Atomic{I,U}64` and 64-bit targets are not affected by this issue. This has been fixed in crossbeam-utils 0.8.7. There are currently no known workarounds. |
| CVE-2022-23486 | libp2p-rust is the official rust language Implementation of the libp2p networking stack. In versions prior to 0.45.1 an attacker node can cause a victim node to allocate a large number of small memory chunks, which can ultimately lead to the victim’s process running out of memory and thus getting killed by its operating system. When executed continuously, this can lead to a denial of service attack, especially relevant on a larger scale when run against more than one node of a libp2p based network. Users are advised to upgrade to `libp2p` `v0.45.1` or above. Users unable to upgrade should reference the DoS Mitigation page for more information on how to incorporate mitigation strategies, monitor their application, and respond to attacks: https://docs.libp2p.io/reference/dos-mitigation/. |
| CVE-2021-47561 | In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: disable timeout handling If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. |
| CVE-2021-46195 | GCC v12.0 was discovered to contain an uncontrolled recursion via the component libiberty/rust-demangle.c. This vulnerability allows attackers to cause a Denial of Service (DoS) by consuming excessive CPU and memory resources. |
| CVE-2021-45710 | An issue was discovered in the tokio crate before 1.8.4, and 1.9.x through 1.13.x before 1.13.1, for Rust. In certain circumstances involving a closed oneshot channel, there is a data race and memory corruption. |
| CVE-2021-45706 | An issue was discovered in the zeroize_derive crate before 1.1.1 for Rust. Dropped memory is not zeroed out for an enum. |
| CVE-2021-45704 | An issue was discovered in the metrics-util crate before 0.7.0 for Rust. There is a data race and memory corruption because AtomicBucket<T> unconditionally implements the Send and Sync traits. |
| CVE-2021-45703 | An issue was discovered in the tectonic_xdv crate before 0.1.12 for Rust. XdvParser::<T>::process may read from uninitialized memory locations. |
| CVE-2021-45699 | An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap. |
| CVE-2021-45695 | An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass. |
| CVE-2021-45694 | An issue was discovered in the rdiff crate through 2021-02-03 for Rust. Window may read from uninitialized memory locations. |
| CVE-2021-45693 | An issue was discovered in the messagepack-rs crate through 2021-01-26 for Rust. deserialize_string_primitive may read from uninitialized memory locations. |
| CVE-2021-45692 | An issue was discovered in the messagepack-rs crate through 2021-01-26 for Rust. deserialize_extension_others may read from uninitialized memory locations. |
| CVE-2021-45691 | An issue was discovered in the messagepack-rs crate through 2021-01-26 for Rust. deserialize_string may read from uninitialized memory locations. |
| CVE-2021-45690 | An issue was discovered in the messagepack-rs crate through 2021-01-26 for Rust. deserialize_binary may read from uninitialized memory locations. |
| CVE-2021-45689 | An issue was discovered in the gfx-auxil crate through 2021-01-07 for Rust. gfx_auxil::read_spirv may read from uninitialized memory locations. |
| CVE-2021-45688 | An issue was discovered in the ash crate before 0.33.1 for Rust. util::read_spv may read from uninitialized memory locations. |
| CVE-2021-45687 | An issue was discovered in the raw-cpuid crate before 9.1.1 for Rust. If the serialize feature is used (which is not the the default), a Deserialize operation may lack sufficient validation, leading to memory corruption or a panic. |
| CVE-2021-45686 | An issue was discovered in the csv-sniffer crate through 2021-01-05 for Rust. preamble_skipcount may read from uninitialized memory locations. |
| CVE-2021-45685 | An issue was discovered in the columnar crate through 2021-01-07 for Rust. ColumnarReadExt::read_typed_vec may read from uninitialized memory locations. |
| CVE-2021-45684 | An issue was discovered in the flumedb crate through 2021-01-07 for Rust. read_entry may read from uninitialized memory locations. |
| CVE-2021-45683 | An issue was discovered in the binjs_io crate through 2021-01-03 for Rust. The Read method may read from uninitialized memory locations. |
| CVE-2021-45682 | An issue was discovered in the bronzedb-protocol crate through 2021-01-03 for Rust. ReadKVExt may read from uninitialized memory locations. |
| CVE-2021-45681 | An issue was discovered in the derive-com-impl crate before 0.1.2 for Rust. An invalid reference (and memory corruption) can occur because AddRef might not be called before returning a pointer. |
| CVE-2021-45680 | An issue was discovered in the vec-const crate before 2.0.0 for Rust. It tries to construct a Vec from a pointer to a const slice, leading to memory corruption. |
| CVE-2021-39219 | Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`. |
| CVE-2021-38190 | An issue was discovered in the nalgebra crate before 0.27.1 for Rust. It allows out-of-bounds memory access because it does not ensure that the number of elements is equal to the product of the row count and column count. |
| CVE-2021-3530 | A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c, as distributed in GNU Binutils version 2.36. A crafted symbol can cause stack memory to be exhausted leading to a crash. |
| CVE-2021-32810 | crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4. |
| CVE-2021-30454 | An issue was discovered in the outer_cgi crate before 0.2.1 for Rust. A user-provided Read instance receives an uninitialized memory buffer from KeyValueReader. |
| CVE-2021-29937 | An issue was discovered in the telemetry crate through 2021-02-17 for Rust. There is a drop of uninitialized memory if a value.clone() call panics within misc::vec_with_size(). |
| CVE-2021-29936 | An issue was discovered in the adtensor crate through 2021-01-11 for Rust. There is a drop of uninitialized memory via the FromIterator implementation for Vector and Matrix. |
| CVE-2021-29934 | An issue was discovered in PartialReader in the uu_od crate before 0.0.4 for Rust. Attackers can read the contents of uninitialized memory locations via a user-provided Read operation. |
| CVE-2021-29932 | An issue was discovered in the parse_duration crate through 2021-03-18 for Rust. It allows attackers to cause a denial of service (CPU and memory consumption) via a duration string with a large exponent. |
| CVE-2021-29930 | An issue was discovered in the arenavec crate through 2021-01-12 for Rust. A drop of uninitialized memory can sometimes occur upon a panic in T::default(). |
| CVE-2021-29511 | evm is a pure Rust implementation of Ethereum Virtual Machine. Prior to the patch, when executing specific EVM opcodes related to memory operations that use `evm_core::Memory::copy_large`, the `evm` crate can over-allocate memory when it is not needed, making it possible for an attacker to perform denial-of-service attack. The flaw was corrected in commit `19ade85`. Users should upgrade to `==0.21.1, ==0.23.1, ==0.24.1, ==0.25.1, >=0.26.1`. There are no workarounds. Please upgrade your `evm` crate version. |
| CVE-2021-28878 | In the standard library in Rust before 1.52.0, the Zip implementation calls __iterator_get_unchecked() more than once for the same index (under certain conditions) when next_back() and next() are used together. This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait. |
| CVE-2021-28877 | In the standard library in Rust before 1.51.0, the Zip implementation calls __iterator_get_unchecked() for the same index more than once when nested. This bug can lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait. |
| CVE-2021-28876 | In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait. |
| CVE-2021-28037 | An issue was discovered in the internment crate before 0.4.2 for Rust. There is a data race that can cause memory corruption because of the unconditional implementation of Sync for Intern<T>. |
| CVE-2021-28036 | An issue was discovered in the quinn crate before 0.7.0 for Rust. It may have invalid memory access for certain versions of the standard library because it relies on a direct cast of std::net::SocketAddrV4 and std::net::SocketAddrV6 data structures. |
| CVE-2021-28035 | An issue was discovered in the stack_dst crate before 0.6.1 for Rust. Because of the push_inner behavior, a drop of uninitialized memory can occur upon a val.clone() panic. |
| CVE-2021-28033 | An issue was discovered in the byte_struct crate before 0.6.1 for Rust. There can be a drop of uninitialized memory if a certain deserialization method panics. |
| CVE-2021-28030 | An issue was discovered in the truetype crate before 0.30.1 for Rust. Attackers can read the contents of uninitialized memory locations via a user-provided Read operation within Tape::take_bytes. |
| CVE-2021-28029 | An issue was discovered in the toodee crate before 0.3.0 for Rust. The row-insertion feature allows attackers to read the contents of uninitialized memory locations. |
| CVE-2021-27377 | An issue was discovered in the yottadb crate before 1.2.0 for Rust. For some memory-allocation patterns, ydb_subscript_next_st and ydb_subscript_prev_st have a use-after-free. |
| CVE-2021-27376 | An issue was discovered in the nb-connect crate before 1.0.3 for Rust. It may have invalid memory access for certain versions of the standard library because it relies on a direct cast of std::net::SocketAddrV4 and std::net::SocketAddrV6 data structures. |
| CVE-2021-26953 | An issue was discovered in the postscript crate before 0.14.0 for Rust. It might allow attackers to obtain sensitive information from uninitialized memory locations via a user-provided Read implementation. |
| CVE-2021-26952 | An issue was discovered in the ms3d crate before 0.1.3 for Rust. It might allow attackers to obtain sensitive information from uninitialized memory locations via IoReader::read. |
| CVE-2021-26951 | An issue was discovered in the calamine crate before 0.17.0 for Rust. It allows attackers to overwrite heap-memory locations because Vec::set_len is used without proper memory claiming, and this uninitialized memory is used for a user-provided Read operation, as demonstrated by Sectors::get. |
| CVE-2021-26308 | An issue was discovered in the marc crate before 2.0.0 for Rust. A user-provided Read implementation can gain access to the old contents of newly allocated memory, violating soundness. |
| CVE-2021-26305 | An issue was discovered in Deserializer::read_vec in the cdr crate before 0.2.4 for Rust. A user-provided Read implementation can gain access to the old contents of newly allocated heap memory, violating soundness. |
| CVE-2021-25905 | An issue was discovered in the bra crate before 0.1.1 for Rust. It lacks soundness because it can read uninitialized memory. |
| CVE-2021-25904 | An issue was discovered in the av-data crate before 0.3.0 for Rust. A raw pointer is dereferenced, leading to a read of an arbitrary memory address, sometimes causing a segfault. |
| CVE-2020-36514 | An issue was discovered in the acc_reader crate through 2020-12-27 for Rust. fill_buf may read from uninitialized memory locations. |
| CVE-2020-36513 | An issue was discovered in the acc_reader crate through 2020-12-27 for Rust. read_up_to may read from uninitialized memory locations. |
| CVE-2020-36512 | An issue was discovered in the buffoon crate through 2020-12-31 for Rust. InputStream::read_exact may read from uninitialized memory locations. |
| CVE-2020-36511 | An issue was discovered in the bite crate through 2020-12-31 for Rust. read::BiteReadExpandedExt::read_framed_max may read from uninitialized memory locations. |
| CVE-2020-36452 | An issue was discovered in the array-tools crate before 0.3.2 for Rust. FixedCapacityDequeLike::clone() has a drop of uninitialized memory. |
| CVE-2020-36432 | An issue was discovered in the alg_ds crate through 2020-08-25 for Rust. There is a drop of uninitialized memory in Matrix::new(). |
| CVE-2020-36317 | In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the same string. |
| CVE-2020-36220 | An issue was discovered in the va-ts crate before 0.0.4 for Rust. Because Demuxer<T> omits a required T: Send bound, a data race and memory corruption can occur. |
| CVE-2020-36217 | An issue was discovered in the may_queue crate through 2020-11-10 for Rust. Because Queue does not have bounds on its Send trait or Sync trait, memory corruption can occur. |
| CVE-2020-36216 | An issue was discovered in Input<R> in the eventio crate before 0.5.1 for Rust. Because a non-Send type can be sent to a different thread, a data race and memory corruption can occur. |
| CVE-2020-36215 | An issue was discovered in the hashconsing crate before 1.1.0 for Rust. Because HConsed does not have bounds on its Send trait or Sync trait, memory corruption can occur. |
| CVE-2020-36211 | An issue was discovered in the gfwx crate before 0.3.0 for Rust. Because ImageChunkMut does not have bounds on its Send trait or Sync trait, a data race and memory corruption can occur. |
| CVE-2020-36210 | An issue was discovered in the autorand crate before 0.2.3 for Rust. Because of impl Random on arrays, uninitialized memory can be dropped when a panic occurs, leading to memory corruption. |
| CVE-2020-36208 | An issue was discovered in the conquer-once crate before 0.3.2 for Rust. Thread crossing can occur for a non-Send but Sync type, leading to memory corruption. |
| CVE-2020-36207 | An issue was discovered in the aovec crate through 2020-12-10 for Rust. Because Aovec<T> does not have bounds on its Send trait or Sync trait, a data race and memory corruption can occur. |
| CVE-2020-36206 | An issue was discovered in the rusb crate before 0.7.0 for Rust. Because of a lack of Send and Sync bounds, a data race and memory corruption can occur. |
| CVE-2020-36203 | An issue was discovered in the reffers crate through 2020-12-01 for Rust. ARefss can contain a !Send,!Sync object, leading to a data race and memory corruption. |
| CVE-2020-35922 | An issue was discovered in the mio crate before 0.7.6 for Rust. It has false expectations about the std::net::SocketAddr memory representation. |
| CVE-2020-35921 | An issue was discovered in the miow crate before 0.3.6 for Rust. It has false expectations about the std::net::SocketAddr memory representation. |
| CVE-2020-35920 | An issue was discovered in the socket2 crate before 0.3.16 for Rust. It has false expectations about the std::net::SocketAddr memory representation. |
| CVE-2020-35919 | An issue was discovered in the net2 crate before 0.2.36 for Rust. It has false expectations about the std::net::SocketAddr memory representation. |
| CVE-2020-35904 | An issue was discovered in the crossbeam-channel crate before 0.4.4 for Rust. It has incorrect expectations about the relationship between the memory allocation and how many iterator elements there are. |
| CVE-2020-35896 | An issue was discovered in the ws crate through 2020-09-25 for Rust. The outgoing buffer is not properly limited, leading to a remote memory-consumption attack. |
| CVE-2020-35893 | An issue was discovered in the simple-slab crate before 0.3.3 for Rust. remove() has an off-by-one error, causing memory leakage and a drop of uninitialized memory. |
| CVE-2020-35891 | An issue was discovered in the ordnung crate through 2020-09-03 for Rust. compact::Vec violates memory safety via a remove() double free. |
| CVE-2020-35890 | An issue was discovered in the ordnung crate through 2020-09-03 for Rust. compact::Vec violates memory safety via out-of-bounds access for large capacity. |
| CVE-2020-35889 | An issue was discovered in the crayon crate through 2020-08-31 for Rust. A TOCTOU issue has a resultant memory safety violation via HandleLike. |
| CVE-2020-35888 | An issue was discovered in the arr crate through 2020-08-25 for Rust. Uninitialized memory is dropped by Array::new_from_template. |
| CVE-2020-35885 | An issue was discovered in the alpm-rs crate through 2020-08-20 for Rust. StrcCtx performs improper memory deallocation. |
| CVE-2020-35881 | An issue was discovered in the traitobject crate through 2020-06-01 for Rust. It has false expectations about fat pointers, possibly causing memory corruption in, for example, Rust 2.x. |
| CVE-2020-35878 | An issue was discovered in the ozone crate through 2020-07-04 for Rust. Memory safety is violated because of the dropping of uninitialized memory. |
| CVE-2020-35877 | An issue was discovered in the ozone crate through 2020-07-04 for Rust. Memory safety is violated because of out-of-bounds access. |
| CVE-2020-35875 | An issue was discovered in the tokio-rustls crate before 0.13.1 for Rust. Excessive memory usage may occur when data arrives quickly. |
| CVE-2020-35873 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated because sessions.rs has a use-after-free. |
| CVE-2020-35872 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via the repr(Rust) type. |
| CVE-2020-35871 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via an Auxdata API data race. |
| CVE-2020-35870 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via an Auxdata API use-after-free. |
| CVE-2020-35869 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated because rusqlite::trace::log mishandles format strings. |
| CVE-2020-35868 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via UnlockNotification. |
| CVE-2020-35867 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via create_module. |
| CVE-2020-35866 | An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via VTab / VTabCursor. |
| CVE-2020-35861 | An issue was discovered in the bumpalo crate before 3.2.1 for Rust. The realloc feature allows the reading of unknown memory. Attackers can potentially read cryptographic keys. |
| CVE-2020-35859 | An issue was discovered in the lucet-runtime-internals crate before 0.5.1 for Rust. It mishandles sigstack allocation. Guest programs may be able to obtain sensitive information, or guest programs can experience memory corruption. |
| CVE-2020-25795 | An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, insert_from can have a memory-safety issue upon a panic. |
| CVE-2020-25794 | An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, clone can have a memory-safety issue upon a panic. |
| CVE-2020-25016 | A safety violation was discovered in the rgb crate before 0.8.20 for Rust, leading to (for example) dereferencing of arbitrary pointers or disclosure of uninitialized memory. This occurs because structs can be treated as bytes for read and write operations. |
| CVE-2020-13759 | 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 read_obj and write_obj do not properly access memory. This affects aarch64 (with musl or glibc) and x86_64 (with musl). |
| CVE-2019-16882 | An issue was discovered in the string-interner crate before 0.7.1 for Rust. It allows attackers to read from memory locations associated with dangling pointers, because of a cloning flaw. |
| CVE-2019-16144 | An issue was discovered in the generator crate before 0.6.18 for Rust. Uninitialized memory is used by Scope, done, and yield_ during API calls. |
| CVE-2019-16137 | An issue was discovered in the spin crate before 0.5.2 for Rust, when RwLock is used. Because memory ordering is mishandled, two writers can acquire the lock at the same time, violating mutual exclusion. |
| CVE-2019-15554 | An issue was discovered in the smallvec crate before 0.6.10 for Rust. There is memory corruption for certain grow attempts with less than the current capacity. |
| CVE-2019-15553 | An issue was discovered in the memoffset crate before 0.5.0 for Rust. offset_of and span_of can cause exposure of uninitialized memory. |
| CVE-2019-15549 | An issue was discovered in the asn1_der crate before 0.6.2 for Rust. Attackers can trigger memory exhaustion by supplying a large value in a length field. |
| CVE-2019-15544 | An issue was discovered in the protobuf crate before 2.6.0 for Rust. Attackers can exhaust all memory via Vec::reserve calls. |
| CVE-2019-15543 | An issue was discovered in the slice-deque crate before 0.2.0 for Rust. There is memory corruption in certain allocation cases. |
| CVE-2019-12083 | The Rust Programming Language Standard Library 1.34.x before 1.34.2 contains a stabilized method which, if overridden, can violate Rust's safety guarantees and cause memory unsafety. If the `Error::type_id` method is overridden then any type can be safely cast to any other type, causing memory safety vulnerabilities in safe code (e.g., out-of-bounds write or read). Code that does not manually implement Error::type_id is unaffected. |
| CVE-2019-1010299 | The Rust Programming Language Standard Library 1.18.0 and later is affected by: CWE-200: Information Exposure. The impact is: Contents of uninitialized memory could be printed to string or to log file. The component is: Debug trait implementation for std::collections::vec_deque::Iter. The attack vector is: The program needs to invoke debug printing for iterator over an empty VecDeque. The fixed version is: 1.30.0, nightly versions after commit b85e4cc8fadaabd41da5b9645c08c68b8f89908d. |
| CVE-2018-25026 | An issue was discovered in the actix-web crate before 0.7.15 for Rust. It can add the Send marker trait to an object that cannot be sent between threads safely, leading to memory corruption. |
| CVE-2018-25025 | An issue was discovered in the actix-web crate before 0.7.15 for Rust. It can unsoundly extend the lifetime of a string, leading to memory corruption. |
| CVE-2018-25024 | An issue was discovered in the actix-web crate before 0.7.15 for Rust. It can unsoundly coerce an immutable reference into a mutable reference, leading to memory corruption. |
| CVE-2018-25008 | In the standard library in Rust before 1.29.0, there is weak synchronization in the Arc::get_mut method. This synchronization issue can be lead to memory safety issues through race conditions. |
| CVE-2018-21000 | An issue was discovered in the safe-transmute crate before 0.10.1 for Rust. A constructor's arguments are in the wrong order, causing heap memory corruption. |
| CVE-2018-20998 | An issue was discovered in the arrayfire crate before 3.6.0 for Rust. Addition of the repr() attribute to an enum is mishandled, leading to memory corruption. |
| CVE-2018-20995 | An issue was discovered in the slice-deque crate before 0.1.16 for Rust. move_head_unchecked allows memory corruption because deque updates are mishandled. |
| CVE-2018-20992 | An issue was discovered in the claxon crate before 0.4.1 for Rust. Uninitialized memory can be exposed because certain decode buffer sizes are mishandled. |
| CVE-2017-20004 | In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions. |
| CVE-2015-20001 | In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory safety violation. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
