UB with ToSocketAddrs and statically linking glibc w/ Oracle Linux 9

[DouglasDwyer]

I tried this code, compiling in debug mode with -C target-feature=+crt-static enabled:

use std::net::ToSocketAddrs;

fn main() {
    drop(("127.0.0.1 localhost", 80u16).to_socket_addrs());
    println!("Success");
}

I expected to see this happen: the program exits and prints Success.

Instead, this happened: When running the program on Oracle Linux 9, the program crashes (killed with signal 11/SEGV) with a segmentation fault, indicating undefined behavior. The program only crashes when statically linking the C runtime.

Meta

rustc --version --verbose:

rustc 1.72.0 (5680fa18f 2023-08-23)
binary: rustc
commit-hash: 5680fa18feaa87f3ff04063800aec256c3d4b4be
commit-date: 2023-08-23
host: x86_64-unknown-linux-gnu
release: 1.72.0
LLVM version: 16.0.5

Backtrace

I collected the backtrace using GDB.

#0  0x00007f712d0cd4d4 in __nss_readline () from /lib64/libc.so.6
#1  0x00007f712d0d06ee in internal_getent () from /lib64/libc.so.6
#2  0x00007f712d0d17a9 in _nss_files_gethostbyname4_r () from /lib64/libc.so.6
#3  0x00007f712d20fadf in gaih_inet.constprop ()
#4  0x00007f712d211629 in getaddrinfo ()
#5  0x00007f712d19ae61 in std::sys_common::net::{impl#6}::try_from::{closure#0} () at library/std/src/sys_common/net.rs:206
#6  0x00007f712d195216 in std::sys::common::small_c_string::run_with_cstr<std::sys_common::net::LookupHost, std::sys_common::net::{impl#6}::try_from::{closure_env#0}> () at library/std/src/sys/common/small_c_string.rs:43
#7  std::sys_common::net::{impl#6}::try_from () at library/std/src/sys_common/net.rs:201
#8  core::convert::{impl#6}::try_into<(&str, u16), std::sys_common::net::LookupHost> () at library/core/src/convert/mod.rs:755
#9  std::net::socket_addr::{impl#10}::to_socket_addrs () at library/std/src/net/socket_addr.rs:266
#10 0x00007f712d17a756 in getaddrinfo_error::main () at src/main.rs:4

[bjorn3]

In Glibc resolving network addresses goes through NSS, which uses dynamically linked libraries. Dynamically linked libraries and statically linked glibc are not compatible. This is the main reason why statically linking glibc is discouraged. Musl doesn't have this problem as it has a /etc/hosts parser and DNS resolver linked into libc itself and never dlopen's any libraries for this. See also https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged

[whentze]

Your backtrace has /lib64/libc.so.6, indicating that a version of glibc was at some point loaded dynamically in addition to the statically linked copy from your binary. Glibc has some best-effort hacks to try and run in this scenario anyway, but you're really already in trouble at that point, and all bets are off.

I suspect that (as @bjorn3 said), NSS is to blame. Specifically, that an NSS module is being loaded which in turn dynamically links to glibc.

I tried to reproduce this on Rocky Linux 9, hoping that it would be similar enough to Oracle Linux (both being RHEL-based), but to no avail. It's possible that there are some extra NSS modules that my installation is not configured to use, or that the Oracle-specific differences somehow cause this.

Which providers for hosts does your NSS have configured? Here are mine:

> grep '^hosts:' /etc/nsswitch.conf
hosts:      files dns myhostname

In any case, I'm not sure how much rust could do here. Perhaps the correct course of action would be a compile-time error when linking statically against libc and trying to use ToSocketAddrs?

[DouglasDwyer]

Which providers for hosts does your NSS have configured?

My providers look exactly the same as yours:

grep '^hosts:' /etc/nsswitch.conf
hosts:      files dns myhostname

[whentze]

I see. So it's likely down to

• what .so exactly is loaded for myhostname or (you could check this using strace, look for the part after it reads nsswitch.conf).
• the exact version(s) of glibc involved

[DouglasDwyer]

@whentze, the issue occurs on glibc 2.34 (I have verified that the problem also occurs on Oracle Linux 8, using glibc 2.28). Using GDB, the only loaded shared libraries upon crashing are:

0x00007ffff7e82050  0x00007ffff7e82109  Yes (*)     /lib64/libnss_files.so.2
0x00007ffff7ca0700  0x00007ffff7e1334d  Yes (*)     /lib64/libc.so.6
0x00007ffff7c42090  0x00007ffff7c67743  Yes         /lib64/ld-linux-x86-64.so.2

So nothing appears to be loaded for myhostname at all, though the system does have a libnss_myhostname.so.2 file on it.

[Noratrieb]

As mentioned, glibc does not really support being statically linked, so this behavior is not unexpected. Maybe we should print a warning when using crt-static on a GNU target.