ltrace crashes when trying to resolve memory mapped shared libraries of an inferior under /proc/self/fd/*
Hello! Similar to a bug I found on GDB,
If any of you will try to dlopen a memory mapped file in the following way:dlopen("/proc/self/fd/4"....)
The operation will trigger ltrace's hook on dlopen and will try to load the file "/proc/self/fd/4".
Obviously ltrace's process has different FD's on /proc/self, and will read from an arbitrary opened file which will cause ltrace to crash.
Here is a rust snippet that will crash ltrace once being debugged:
use std::{os::unix::prelude::{AsFd, AsRawFd}, io::Write};
use memfd;
use dlopen_derive::{self, WrapperApi};
#[macro_use]
use dlopen::wrapper::{Container,WrapperApi};
#[derive(WrapperApi)]
struct Api<'a> {
example_rust_fun: fn(arg: i32) -> u32,
example_c_fun: unsafe extern "C" fn(),
example_reference: &'a mut i32,
}
fn main() {
let opts = memfd::MemfdOptions::default().allow_sealing(true);
let mfd = opts.create("hellooo").unwrap();
let buff = std::fs::read("/usr/lib64/ld-linux-x86-64.so.2").unwrap();
mfd.as_file().write(buff.as_slice()).unwrap();
let fd = mfd.as_file().as_fd().as_raw_fd();
let fm = format!("/proc/self/fd/{}", fd);
println!("{}", fm);
let mut cont: Container<Api> =
unsafe { Container::load(fm) }.expect("Could not open library or load symbols");
}
I can easily submit a patch later this week.
Edited by Asaf Fisher