Segmentation fault when initializing tls on 1.51.0-x86_64-unknown-linux-musl

[seanpianka]

First, add this Dockerfile:

FROM rust:1.51.0-alpine3.12
ADD . /root/bugtest
RUN apk update \
    && apk add --no-cache \
        musl-dev \
        gdb \
        alpine-sdk \
        openssl-dev \
        vim \
    && rustup toolchain add nightly-2021-03-09 \
    && rustup show
RUN cd /root/bugtest \
    && cargo clean \
    && cargo test

Then, create a new binary with $ cargo new bugtest, and add the following contents:
src/main.rs:

#[cfg(test)]
mod tests {
    #[test]
    fn should_not_segfault() {
        let _ = openssl::ssl::SslMethod::tls();
    }
}

Cargo.toml:

[package]
name = "opensslbug"
version = "0.1.0"
authors = ["Sean"]
edition = "2018"

[dependencies]
openssl = "0.10"

Finally, invoke $ docker build -f Dockerfile -t bug:latest . and see the output containing the seg-fault:

Step 4/4 : RUN cd /root/bugtest     && cargo clean     && cargo test
...
...
     Running target/debug/deps/opensslbug-32d8fefb19f1f2a5

running 1 test
error: test failed, to rerun pass '--bin opensslbug'

Caused by:
  process didn't exit successfully: `/root/bugtest/target/debug/deps/opensslbug-32d8fefb19f1f2a5` (signal: 11, SIGSEGV: invalid memory reference)
The command '/bin/sh -c cd /root/bugtest     && cargo clean     && cargo test' returned a non-zero code: 101

[seanpianka]

See previous discussion in an issue from the downstream crate cargo-udeps.

[lo48576]

fn main() {
    match std::env::args().nth(1).as_deref() {
        Some("0") => {
            let _ = openssl::ssl::SslMethod::tls();
        }
        Some("1") => {
            let _ = openssl::ssl::select_next_proto(&[0, 1], &[1, 2]);
        }
        Some("2") => {
            let s = openssl::ssl::cipher_name("DUMMY");
            assert_eq!(s, "(NONE)");
        }
        _ => {}
    }
}

• Docker container: rust:1.51.0-alpine3.12
• openssl crate: 0.10.33
• openssl-dev package: 1.1.1k-r0

I tried this code, and cargo run 0, cargo run 1, and cargo run 2 segfaulted.
cargo run exits successfully, so I guess the problem might be caused on the first call to the functions which invoke FFI calls behind that.

[sfackler]

The system-installed copy of OpenSSL dynamically links to the system MUSL, but Rust will by default statically link to a bundled MUSL, and that causes things to break when calling into OpenSSL.

You should either build an OpenSSL that also statically links to MUSL (e.g. with the vendored cargo feature), or tell Rust to also dynamically link to the system musl by setting RUSTFLAGS=-Ctarget-feature=-crt-static.

[est31]

This is probably interesting in this context:

• add dynamically-linked musl targets rust-lang/rust#82556
• Update the existing musl targets to be dynamically linked. rust-lang/compiler-team#422

[polarathene]

For reference, this was likely due to a bug with +crt-static that affected the x86_64-unknown-linux-musl and similar targets defaulting to static linking. It was resolved in Oct 2023 with Rust 1.72: rust-lang/rust#82912