Potential Undefined Behavior Reported by Miri

[yilin0518]

Hi!

We are a team of researchers studying the memory safety problem in Rust. As part of our ongoing research, we performed random testing on aliasable (version: 0.1.3) and found that the following code snippet is reported as undefined behavior by Miri:

#![feature(allocator_api)]
use aliasable::*;
fn main() {
    let v52 = "";
    let v53 = String::from(v52);
    let v54 = <string::AliasableString as core::convert::From<string::UniqueString>>::from(v53);
}

I detected the UB using the command: cargo +nightly-2025-09-10 miri run
And the error information Miri threw out is:

error: Undefined Behavior: pointer not dereferenceable: pointer must be dereferenceable for 1 byte, but got 0x1[noalloc] which is a dangling pointer (it has no provenance)
   --> /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:481:18
    |
481 |         unsafe { &mut *self.as_ptr() }
    |                  ^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE:
    = note: inside `std::ptr::NonNull::<u8>::as_mut::<'_>` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:481:18: 481:37
    = note: inside `aliasable::vec::AliasableVec::<u8>::reclaim_as_unique_vec` at /home/chenyl/projects/Itgen_test/extra/aliasable-0.1.3/src/vec.rs:68:35: 68:52
    = note: inside `<aliasable::vec::AliasableVec<u8> as std::ops::Drop>::drop` at /home/chenyl/projects/Itgen_test/extra/aliasable-0.1.3/src/vec.rs:91:26: 91:54
    = note: inside `std::ptr::drop_in_place::<aliasable::vec::AliasableVec<u8>> - shim(Some(aliasable::vec::AliasableVec<u8>))` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:804:1: 804:62
    = note: inside `std::ptr::drop_in_place::<aliasable::string::AliasableString> - shim(Some(aliasable::string::AliasableString))` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:804:1: 804:62
note: inside `main`
   --> src/main.rs:7:1
    |
  7 | }
    | ^

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

error: aborting due to 1 previous error; 1 warning emitted

Also, the following code snippet triggers UB:

#![feature(allocator_api)]
use aliasable::*;
fn main() {
    let v5 = "";
    let v6 = String::from(v5);
    let v7 = string::AliasableString::from_unique(v6);
}

The corresponding error information is:

error: Undefined Behavior: pointer not dereferenceable: pointer must be dereferenceable for 1 byte, but got 0x1[noalloc] which is a dangling pointer (it has no provenance)
   --> /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:481:18
    |
481 |         unsafe { &mut *self.as_ptr() }
    |                  ^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE:
    = note: inside `std::ptr::NonNull::<u8>::as_mut::<'_>` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:481:18: 481:37
    = note: inside `aliasable::vec::AliasableVec::<u8>::reclaim_as_unique_vec` at /home/chenyl/projects/Itgen_test/extra/aliasable-0.1.3/src/vec.rs:68:35: 68:52
    = note: inside `<aliasable::vec::AliasableVec<u8> as std::ops::Drop>::drop` at /home/chenyl/projects/Itgen_test/extra/aliasable-0.1.3/src/vec.rs:91:26: 91:54
    = note: inside `std::ptr::drop_in_place::<aliasable::vec::AliasableVec<u8>> - shim(Some(aliasable::vec::AliasableVec<u8>))` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:804:1: 804:62
    = note: inside `std::ptr::drop_in_place::<aliasable::string::AliasableString> - shim(Some(aliasable::string::AliasableString))` at /home/chenyl/.rustup/toolchains/nightly-2025-09-10-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:804:1: 804:62
note: inside `main`
   --> src/main.rs:7:1
    |
  7 | }
    | ^

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

error: aborting due to 1 previous error; 1 warning emitted

We’d appreciate it if you could take a look and confirm whether this behavior indicates a real issue, or if it’s a false positive or an expected limitation of Miri.

Thank you very much for your time and for maintaining this great project! 🙏

[avitex]

Hello! Just acknowledging this report, thank you for the testing. I'll have a look in the next few days :)

[avitex]

Confirming I have reproduced this on a checkout of 0.1.3 however this is fixed on master but just never got released. Before I release this I will want to make sure this doesn't break downstream usage, which will have to wait for a few days

[yilin0518]

Hello! Just acknowledging this report, thank you for the testing. I'll have a look in the next few days :)

Thank you！If you want to reproduce thie error using Miri, you can use the following command:
MIRIFLAGS="-Zmiri-ignore-leaks -Zmiri-disable-stacked-borrows -Zmiri-disable-isolation" RUSTFLAGS=-Awarnings RUST_BACKTRACE=1 cargo +nightly-2025-09-10 miri run
This is the command we conduct experiment. Also cargo +nightly-2025-09-10 miri run can trigger UB.

[avitex]

I'm assuming this is within another project. My reproduction with this project was with cargo +nightly-2025-09-10 miri test

[yilin0518]

I'm assuming this is within another project. My reproduction with this project was with cargo +nightly-2025-09-10 miri test

The code snippet is a cargo project that we create for Miri run, so I didn't use Miri to test aliasable.

[meowette]

any updates on this?

[ggirol-rc]

fwiw I also observed that the reproducer in this issue works with v0.1.3 and does not work with current master. Could a release be cut with current master ?