Most recent entries from osv_rustsec

RUSTSEC-2026-0319 — anymap2 is unmaintained

Fri, 02 Oct 2026 12:00:00 +0000

Affected: crates.io: anymap2

The `anymap2` crate is not maintained. `anymap3` is the recommended replacement.

RUSTSEC-2026-0318 — Sending custom to-device messages may panics

Tue, 29 Sep 2026 12:00:00 +0000

Affected: crates.io: matrix-sdk-crypto

Using the `IdentityBasedStrategy` setting when calling `Device::encrypt_event_raw` or `OlmMachine::encrypt_content_for_devices` may cause a panic if the recipient does not have cross-signing keys.

RUSTSEC-2026-0317 — A 512-byte workbook can provoke a multi-gigabyte allocation and abort the process

Tue, 29 Sep 2026 12:00:00 +0000

Affected: crates.io: sheets-diff

Affected versions passed caller-supplied bytes to `calamine`'s `Xlsx::new` without first checking that they were a ZIP archive. `Xlsx::new` tests for password protection on its first line, which parses the input as an OLE/CFB container, and a sector-count field read from the file's own header reaches `Vec::with_capacity` without being checked against the file's actual length. A 512-byte input can therefore request several gigabytes; 9,261,285,372 bytes was measured.

**The oversized allocation is always attempted. Whether it aborts depends on what the allocator can satisfy.** On a large host with overcommit the reservation is granted untouched and the call returns an ordinary "not an xlsx file" error, which looks like a malformed file being correctly rejected. Under a memory limit the same bytes give `memory allocation of N bytes failed` and the process aborts, which is not a `Result` a caller can handle. Containers with a memory limit, small hosts and CI runners are where this lands, so testing on a development machine can wrongly suggest the crate is unaffected.

Every entry point reaches it, not only `compare_bytes`: the path- and reader-based APIs funnel through the same internal open. Neither `Limits::default()` nor `Limits::hardened()` prevents it, because `max_input_bytes` bounds the length of the input while the allocation's size comes from a field inside it.

Fixed in 3.2.0, which declines input that does not begin with the ZIP magic before the parser sees it, remov…

RUSTSEC-2026-0311 — Stack overflow on deeply nested LaTeX input

Sun, 27 Sep 2026 12:00:00 +0000

Affected: crates.io: latex-rust

The parser and layout engine in affected versions of `latex-rust` recurse once per level of nesting with no limit. Deeply nested input, such as `\frac{1}{…}`, braces, `\sqrt{…}`, `\left(`, or superscripts nested hundreds or thousands of levels deep, exhausts the call stack.

A stack overflow in Rust aborts the process. It is not a panic, so it cannot be caught with `catch_unwind`. A program that renders LaTeX from untrusted input can therefore be terminated by a short string. With a release build on an 8 MiB stack, 700 nested `\frac{1}{…}` (about 7 KB of input) abort version 1.0.4, and 10,000 nested braces (about 20 KB) abort it as well. The threshold is lower on smaller stacks and in debug builds; on a 2 MiB thread in a debug build, about 35 nested fractions are enough.

```rust let mut src = String::from("1"); for _ in 0..700 { src = format!("\\frac{{1}}{{{src}}}"); } let _ = latex_rust::parse(&src); // stack overflow, process aborts ```

The fixed versions count nesting depth in the parser and in `layout` and refuse input that nests more than 32 levels. `parse`, `parse_with_colors`, and the `latex_to_*` functions return `ParseError::Malformed("input nests deeper than 32 levels")`, and `layout` returns `Error::Unsupported { what: "tree nests deeper than 32 levels" }` for a tree built by hand. The count is of parser recursion levels, and a braced argument costs two, so the limit admits 15 nested `\frac`, `\sqrt`, or `x^{…}`, and 31 nested groups, `\left…\right` pairs, o…

RUSTSEC-2026-0310 — Various panics, soundness and resource exhaustion issues

Fri, 25 Sep 2026 12:00:00 +0000

Affected: crates.io: domain

Version 0.12.3 fixes a large number of panics, soundness issues, and CPU and memory exhaustion issues in all parts of the crate.

The following is a summary of the issues per affected components. For details, please see the [release notes](https://github.com/NLnetLabs/domain/releases/tag/v0.12.3).

## Base

* Limited the number of compression pointers that are followed when parsing a compressed name to 255 to avoid following really long chains. * Limited the length of CNAME chains followed by `Message::canonical_name` to 20. This also fixed an integer overflow in this method when ANCOUNT was`u16::MAX`. * Changed `QuestionSection::answer` to skip over all remaining questions without parsing the QNAMEs to avoid being slowed down by malicious names. * Added length checks when scanning and parsing variable length record data types. This fixes issues with the message builder, which assumes that record data is never too large for placing in a message.

## Stub Resolver

* Fixed possible panics in the resolver’s `FoundHosts::qname` and `FoundHosts::canonical_name`. * Fixed various issues in SRV processing.

## Zonefile parsing

* Fixed soundness issues when reading UTF-8 and an integer overflow when reading unsigned integers. * Fixed a panic when reading empty TXT records.

## Client and server transports, DNSSEC signer and validator

Fixed various panics that could be triggered by malicious incoming DNS messages.

## Zonetree

Fixed various panics and a memory ex…

RUSTSEC-2026-0316 — Dynamic record lifting can allocate beyond the hostcall fuel limit