Rust invalid free in MetaCallException::new and other unsoundness issues

[thanasistrisp]

Hello! I found several memory related vulnerabilities I would like to report in https://crates.io/crates/metacall crate at latest version 0.5.10.

Memory corruption in MetaCallException::new / Drop

#[test]
fn exception_bad_free_safe_api() {
    let original = metacall::MetaCallException::new(
        "test",
        "test",
        "test",
        1,
    );

    drop(original);
}

Running this test with ASAN, I got the following report:

METACALL_INSTALL_PATH=/path/to/metacall-install \
LD_LIBRARY_PATH=/path/to/metacall-install/lib:$LD_LIBRARY_PATH \
RUSTFLAGS="-Zsanitizer=address" \
cargo +nightly test --test metacall_exception_test exception_bad_free_safe_api -- --nocapture

SUMMARY: AddressSanitizer: bad-free /core/source/reflect/source/reflect_exception.c:330:4 in exception_destroy
==3120305==ABORTING

exception_struct is a local stack variable, but the code passes its address to C: &mut exception_struct as *mut _ as *mut c_void.
Then the returned MetaCall value is stored here:

Ok(Self {
    exception_struct: Arc::new(exception_struct),
    value: exception_ptr,
    leak: false,
})

Because leak is false, the destructor will run later. But the original exception pointer points to Rust stack memory. Address sanitizer reports bad-free.

Possible solution: the struct should be heap allocated if it is intended to pass on C.

For compiling with ASAN, because the repro does not use inline macros, I locally disabled that module in src/lib.rs:116:

#[cfg(any())]
pub mod inline {
    pub use metacall_inline::*;
}

Other issues (unsoundness)

The following issues are referring to src/types/metacall_exception.rs but very similar issues should exist to src/types/metacall_class.rs, src/types/metacall_future.rs, src/types/metacall_pointer.rs, src/issues/metacall_function.rs, src/issues/metacall_object.rs, src/event/event_handler.rs and src/load.rs.

• Clone traits seem dangerous because value is shallow copied and leak=true does not guarantee safety; Clone does not free the MetaCall value, but it still stores the same raw pointer. If the original is dropped, the clone can retain a dangling pointer (value).
• new_raw method is a safe function that accepts arbitrary raw pointer and dereferences C memory. This function is only correct if the caller gives it a valid, owned MetaCall value that must be destroyed by this wrapper. The method should be even internal and not exposed to the public API or be declared as unsafe (and be correctly documented).

[viferga]

Thank you so much for reporting, can you share this:

1. OS dand version.
2. rust -vV
3. Underlaying c compiler (gcc, clang?) and toolset you are using for sanitizers.

I would like to setup a CI with sanitizer but I never made it work properly on rust.

[thanasistrisp]

Debian GNU/Linux 12 (bookworm)

Stable rust version:

rustc 1.93.0 (254b59607 2026-01-19)
binary: rustc
commit-date: 2026-01-19
host: x86_64-unknown-linux-gnu
release: 1.93.0
LLVM version: 21.1.8

Nightly rust version (for ASAN):

rustc 1.95.0-nightly (f60a0f1bc 2026-02-02)
binary: rustc
commit-date: 2026-02-02
host: x86_64-unknown-linux-gnu
release: 1.95.0-nightly
LLVM version: 22.1.0

gcc (Debian 12.2.0-14+deb12u1) 12.2.0
Debian clang version 14.0.6
/usr/lib/gcc/x86_64-linux-gnu/12/libasan.so

[viferga]

Thank you so much! Feel free to PR any improvement you want.

[thanasistrisp]

Can you please confirm whether publishing a RustSec advisory for this issue(s) is appropriate?

[viferga]

I don't think so, most of the consumers of the rust port is basically ourselves in other repositories.

[viferga]

I mean, can you explain what's the benefit of publishing it there?

[thanasistrisp]

Especially for the first vulnerability, just calling the safe public constructor MetaCallException::new(...) is the intended/normal use and free on non-allocated memory is an exploitable vulnerability. If a RustSec advisory is issued for the affected versions, then any repo running cargo audit in CI (including your own) gets flagged automatically. Also, since this crate has ~20k all time downloads the previous is important but also consider to yank all the affected versions when you have a fix.

[viferga]

You're right, then open it.

[djc]

Do you intend to publish fixed releases for this soon(ish)?

[viferga]

Do you intend to publish fixed releases for this soon(ish)?

What does that mean?

[djc]

Do you have a plan to publish a new release of this crate that addresses these issues, and if so, how long do you think it will take until fixes are published?

[viferga]

Do you have a plan to publish a new release of this crate that addresses these issues, and if so, how long do you think it will take until fixes are published?

I have a list of TODOs before reaching this.

I have tried to remove most of the issues you have pointed out for a long time but Rust is very different from C/C++ and the tooling used not to work for instrumenting it, apart that I am a noob compared to the knowledge I have in C/C++.

My idea was always been to remove the poor modelling and implementation we have in Rust and validate it with sanitizers and full coverage.

I can show you examples and trials on those:
#529

Or the instrumentation:

core/source/ports/rs_port/CMakeLists.txt

Line 36 in e75af84

set(RS_PORT_INSTRUMENTATION_NIGHTLY_VERSION 2023-05-24)

I would like to achieve something like this in fact, this is the equivalent API in C++ to show you my idea (I want even to use HLists as frontend for the final API):

core/source/tests/metacall_cxx_port_test/source/metacall_cxx_port_test.cpp

Line 135 in e75af84

{

But right now I have many other projects ongoing and other features, this goes to the bottom of that list.

Do you need it for a software you're developing? Or are you interested in contributing?

[djc]

I maintain the RustSec advisory database. We prefer to publish advisories which can reference a version that fixes the issue. It sounds like in this case publishing the advisory should not wait for a fixed version to be published.