Rust Had a Memory Safety Bug for 11 Years #rust #programming #security
Read the Portuguese translation →
Author: Better Stack · Watch on YouTube
Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.
Original language: English
Original video: Rust Had a Memory Safety Bug for 11 Years #rust #programming #security · Channel: Better Stack · 01:36 · Watch on YouTube
Topics: Cybersecurity and software security, Software engineering with AI
Summary
Section titled “Summary”Rust is designed to prevent memory from being accessed after it is freed, but an issue reported in the Rust repository describes a way to do this with safe Rust. The bug involves a struct with a ’static lifetime bound and a drop function that relies on that promise, while an assignment of a shorter-lived reference is not rejected. A compiler contributor found the issue had existed since Rust 1.4 in 2015. The speaker says it requires deliberately abusing a drop function, so it is high priority rather than critical, and notes that compilers are code too.
Key points
Section titled “Key points”- Rust’s compiler is intended to prevent access to memory after it has been freed.
- Issue 164250 was opened in the Rust repository and received the unsound label.
- The example uses a struct whose contents are required to live for the ’static lifetime.
- A drop function trusts the struct’s lifetime promise.
- The compiler does not reject assigning a reference to a shorter-lived string into the struct’s field.
- When the struct is dropped, its drop code can use a reference to memory that is about to be freed.
- One example passes the reference to a thread that prints it a second later, reading freed memory.
- A compiler contributor found the bug had been unsound since Rust 1.4, in 2015.
- The bug requires deliberately abusing a drop function, which is why it is high priority rather than critical.
Chapters
Section titled “Chapters”| Start | Chapter | Summary |
|---|---|---|
| 00:00 | The Rust memory safety bug | The video introduces a Rust issue that allows safe code to access freed memory and explains the struct’s ’static lifetime promise. |
| 00:31 | How the bug can read freed memory | The compiler allows a shorter-lived string reference to be assigned to the struct, and the drop code can later pass it to a thread. |
| 01:05 | A bug dating back to Rust 1.4 | The speaker says the issue dates to 2015, explains why it is high priority rather than critical, and concludes that compilers are code too. |
Quotes
Section titled “Quotes”That’s the worst kind of bug a compiler can have. — 00:00
The compiler should reject that. It doesn’t. — 00:31
How on Earth has this not been found before? — 01:05
Memory safe is a promise made by a compiler, and compilers are code, too. — 01:05
Concepts and entities
Section titled “Concepts and entities”Rust, Rust repo, issue 164250, static bound, drop, Godbolt, Rust 1.4
Full transcript (original language)
Section titled “Full transcript (original language)”00:00 Rust’s whole deal is that the compiler won’t let you touch memory after it’s freed. But for 11 years, you could do exactly that in about 10 lines of safe Rust. Let me explain. Last week, someone opened issue 164250 on Rust repo, and it got the unsound label. That’s the worst kind of bug a compiler can have. Here’s how it works. You make a struct that says, “Whatever I hold has to live forever.” That’s the static bound. Then you write a drop
00:31 function that trusts that promise. Now, in main, you create a normal string that only lives for a few lines. You create the struct empty, and then you assign a reference to that string into its field. The compiler should reject that. It doesn’t. It never checks the struct’s lifetime rule on that assignment. So, when the struct gets dropped, your drop code is holding a lives forever reference in a string that’s about to be freed. One version hands it to a thread that prints it a second later, and now you’re reading freed memory. And here’s
01:05 the craziest part. A compiler contributor ran it on a Godbolt and found it’s been unsound since Rust 1.4, back in 2015. The person who found it literally wrote, “How on Earth has this not been found before?” The good news is you won’t hit this by accident. You’d have to write a drop that deliberately abuses it, which is why it’s tagged high priority, not critical. Memory safe is a promise made by a compiler, and compilers are code, too. If you want
01:36 more coding tips and tricks like this, be sure to subscribe to the Better Stack channel.