Have I missunderstood Rust ?

[bens_dad]

There is a new Rust security alert: Rustsec-2026-0007 aka CVE‑2026‑25541.
I'm taking my understanding of this bug from
https://windowsforum.com/threads/rust-bytes-vulnerability-cve-2026-25541-memory-safety-in-bytesmut-reserve.403939/

As I understand it, Rust is a computer language designed and "sold" as being much safer than other fast languages, such as C and C++ precisely because those languages are very susceptible to bugs like this.

What am I missing ?

Comments

[crazyscot]

This particular issue is specific to the bytes package. It's an integer overflow that permits memory corruption, though does not directly cause RCE.

Rust provides you with the tooling to design out a whole class of traditional vulnerabilities, but it is not impervious. For example, you get integer overflow checks out of the box, but only in debug builds. You also have the option of using saturating arithmetic, or always-checked (even in release builds), or always-overflowing, if any of those better suit.

Buffer accesses of all sorts (dynamic vectors, static arrays, and various other containers) are all checked at runtime, in debug and release builds. You also have the option of bypassing the safeguards and accessing raw memory if you feel the need (via an explicit unsafe declaration): that serves as a sigil to reviewers, that this code needs extra care. The philosophy is that undefined behaviour should be prevented as much as possible, but the safeguards may not suit every situation so there is an escape hatch.

For me, the real novelty about Rust is the concept of memory ownership. Unlike in C or C++, you cannot share pointers willy-nilly (outside of unsafe blocks). Every piece of memory - stack, heap or static; primitive or complex - has precisely one owner and a defined lifetime. The lifetime gives automatic deallocation (much like RAII semantics in C++). If you transfer ownership to another function, the compiler prevents you from using it afterwards. But you can also borrow memory. Again this is compiler-enforced: one function might keep ownership of a struct, but pass it on temporarily to another function.

Ownership also controls mutability. If you own memory, you decide whether or not it's mutable. But if you are passed an immutable borrow of an item, you cannot make it mutable. Like read-only and read-write locks, you can pass on as many immutable borrows simultaneously as you like, but only one mutable borrow; and while there's a borrow out on an item, you (the owner) can only borrow it yourself under the same rules. Alongside all this there's also the ability to design in temporary mutability, for more complicated setups.

It has really forced me to up my game in terms of memory design. When I got the hang of it I found it actually makes life easier. I can refactor with confidence (and that is precisely another philosophical point behind the language).