rust-lang / rust-lang/rust

Annotating the type of transmute of a const causes a reborrow and retag, increasing the amount of UB

Open
#146,917 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-const-eval A-MIR A-miri C-bug I-lang-radar T-compiler T-opsem
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

I tried this code:

use std::mem::transmute;
const A: &u8 = unsafe { transmute(&0u64) };
fn main() {
    // This is ok
    let _x: &u64 = unsafe { transmute::<_, _>(A) };
    // We can even read through the reference
    let _y = *_x;
    // This is UB
    let _z: &u64 = unsafe { transmute::<&_, _>(A) };
}

I expected the transmutes to either be both OK or both UB. Instead, only the second transmute is detected as UB by Miri.

error: Undefined Behavior: trying to retag from <298> for SharedReadOnly permission at alloc3[0x1], but that tag does not exist in the borrow stack for this location
 --> src/main.rs:9:29
  |
9 |     let _z: &u64 = unsafe { transmute::<&_, _>(A) };
  |                             ^^^^^^^^^^^^^^^^^^^^^ this error occurs as part of retag at alloc3[0x0..0x8]
  |
  = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
  = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <298> was created by a SharedReadOnly retag at offsets [0x0..0x1]
 --> src/main.rs:9:48
  |
9 |     let _z: &u64 = unsafe { transmute::<&_, _>(A) };
  |                                                ^
  = note: BACKTRACE (of the first span):
  = note: inside `main` at src/main.rs:9:29: 9:50

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

The relevant MIR is:

    bb0: {
        _1 = const A as &u64 (Transmute);
        _2 = copy (*_1);
        _4 = const A;
        _3 = move _4 as &u64 (Transmute);
        return;
    }

It seems to me that:

  • The A const has provenance that can access the entire 8 bytes of the u64.
  • transmute is not a typed copy, so it preserves that provenance when the type isn't annotated
  • Annotating the type, for some reason, causes a typed copy of A to happen before transmuting, shrinking the provenance.

(Note that other means of causing a typed copy, such as adding a brace so it's transmute::<_, _>({A}), also causes UB.)

See also https://github.com/rust-lang/rust/issues/143671 and https://github.com/rust-lang/rust/issues/140123, where annotating a type changes the behavior of the program.

Meta

Reproducible on the playground with Rust version 1.92.0-nightly (2025-09-21 9f32ccf35fb877270bc4) and Miri version 0.1.0 (2025-09-21 9f32ccf35f)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the example from src/main.rs with the stated nightly Rust and Miri versions, then compare the shown MIR for the annotated and unannotated transmute cases. Investigate how typed copies, provenance, reborrowing, and retagging are handled; done means the behavior is specified or corrected and covered by a regression test.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.