Rust borrow checker soundness bug, 11 years old, rated P-high
Issue #164250 in the rust-lang/rust repository, opened on Oct 13, 2026, reports a soundness hole in the borrow checker. A struct's lifetime requirements, such as a T: 'static bound, can be bypassed through assignment to a covariant field. As a result, a Drop implementation can receive a non-'static reference while assuming it is 'static.
The reporter's example defines struct Q<T: 'static + Send>(Option
The issue was triaged within the day. Labels added on Oct 13 include I-unsound (a soundness hole, described as the worst kind of bug), A-borrow-checker, T-types, A-destructors, A-lifetimes and A-variance. The title was changed from "struct's T: 'static bound bypassed via covariant field assignment" to "struct's lifetime requirements can be bypassed via covariant field assignment".
A note at the top, signed lcnr, was added because the issue was being shared online and drawing many visitors. It says Rust's type system is intended to prevent memory unsafety and that the team takes this seriously, citing work on the next-generation trait solver, the region constraint rework and Project Zero. Fixing all type system unsoundnesses is a large priority of the Types Team. The bug is P-high and would have been P-critical regardless of whether anyone hit it in the wild; it is "only P-high" because it is 11 years old, and a bug that went unfound for 11 years cannot actually be that easy to hit. The note also calls it very likely that the unsoundness has not caused memory unsafety by accident: it looks easy to trigger, but exploiting it takes an intentionally malicious Drop implementation.
The thread added several variants. One avoids the 'static bound altogether, using a struct with a mutable reference and a Drop that writes a shorter-lived reference through it. One commenter says their version of the code has compiled ever since 1.18.0 (2017) and asks how it went unnoticed. Another says a variant segfaults or prints freed memory since 1.4. A third, described by its author as probably the easiest to understand, spawns a thread from Drop that prints a dangling &String a second later. One commenter suggests that unification generally does not check lifetime bounds of the type, and shows a case with unifying coercion and no field assignment. Another links issue #128225 as possibly related.
A moderator locked the thread preventively to prevent spam and unhelpful comments, and it was locked, unlocked and locked again to collaborators on Oct 13. The issue still shows as open and unblocked, with a commit referencing it.
Key facts
- Rust issue #164250 reports that a struct's lifetime requirements, such as T: 'static, can be bypassed via covariant field assignment, so a Drop implementation can see a non-'static reference.
- The reproducer compiles and prints the contents of a dead local's memory; under AddressSanitizer it crashes with stack-use-after-scope.
- Reported on current nightly and on stable at least down to 1.85.0.
- Maintainer lcnr says it is P-high only because it is 11 years old, and that exploiting it needs an intentionally malicious Drop implementation.
- The issue is labelled I-unsound and T-types and is open; no fix or release version is stated.
Why it matters
Rust's central promise is that safe code cannot cause memory unsafety, and the type system is what enforces it. This issue shows a program the compiler accepts that reads memory from a scope that has already ended. The maintainers treat it as a real soundness hole: the note says it would have been P-critical regardless of whether people encountered it in the wild, and it carries the I-unsound label. The Types Team ties it to its ongoing work on the next-generation trait solver, the region constraint rework and Project Zero.
Who it affects
In principle, anyone compiling Rust: the reporter lists current nightly and stable versions at least down to 1.85.0. In practice the maintainers argue that ordinary code is unlikely to be hit. Their note says the bug has very likely not caused memory unsafety by accident and that exploiting it requires an intentionally malicious Drop implementation. That puts the sharpest concern on setups that rely on the compiler to contain untrusted or third-party code that implements Drop.
How to use it
There is nothing to adopt here; it is a bug report. The issue includes a short reproducer and two Godbolt links, one with AddressSanitizer and one without, so you can watch the compiler accept the program and the sanitizer flag the use after scope. No fix is stated as merged or released.
How solid is it
Solid. It is the official rust-lang/rust issue with a runnable reproducer, triaged by the team the same day with soundness and borrow checker labels, and a maintainer note confirms the priority. The 11-year age is stated by lcnr. Claims in the comments, such as the code compiling since 1.18.0 (2017) or a variant misbehaving since 1.4, come from commenters and are not confirmed by the maintainers' note.
Risks and caveats
The maintainers' note calls the bug hard to hit by accident, but also says it looks easy to trigger deliberately. No real-world exploitation or incident is described in the source. The headline's plural "bugs" on Hacker News aside, the issue concerns one unsoundness with several reproducing variants. No timescale for a fix and no release version are given, and the thread is locked to collaborators, so further detail will come from the team rather than from the comments.
“A bug like this which has not been found during the last 11 years cannot actually be that easy to hit.”
— lcnr, note at the top of rust-lang/rust issue #164250