Loading glibc in a new namespace fails vtable check

Florian Weimer fweimer@redhat.com
Thu Sep 26 15:58:38 GMT 2024


* Moshe Rubin:

> libc_fwrite = reinterpret_cast<decltype(libc_fwrite)>(dlsym(handle, "fwrite"));
> size_t ret = libc_fwrite("Hello, world!\n", 1, 14, stderr);
> printf("ret = %lu\n", ret);
> </code>
>
> Here is the run's output:
>
> <output>
> $ ./minimal_example /usr/lib/x86_64-linux-gnu/libc.so.6
> glibc path: /usr/lib/x86_64-linux-gnu/libc.so.6
> fd = 2
> Hello, world!
> ret = 14
> </output>
>
> Still no fatal error.  I really want to reproduce the fatal error.

The stderr stream should be unbuffered, so fwrite should trigger a
vtable call.

Maybe what the application does is in the other direction, though: using
stderr from the inner libc with the initial libc?

That crashes for me:

#include <gnu/lib-names.h>
#include <stdio.h>
#include <support/xdlfcn.h>

static int
do_test (void)
{
  void *handle = xdlmopen (LM_ID_NEWLM, LIBC_SO, RTLD_NOW);
  FILE **inner_stderr = xdlsym (handle, "stderr");
  fputs ("crash?\n", *inner_stderr);
  return 0;
}

#include <support/test-driver.c>

And this is arguably a bug.  My original plan was to disable vtable
hardening when dlmopen is called, but we currently do not do that.

Thanks,
Florian



More information about the Libc-help mailing list