[PATCH] elf: Fix dlclose of an empty namespace in auditing mode (bug 26076)

[Florian Weimer]

* Carlos O'Donell:

> On 6/3/20 9:43 AM, Florian Weimer via Libc-alpha wrote:
>> ns->_ns_loaded is NULL if nothing has been loaded into the namespace.
>> 
>> It seems difficult to hit this bug reliably, so this change does not
>> come with a test case.  It was trigger by accident, due to TLS
>> exhaustion.
>
> I think this should fail catastrophically and quickly.

Why should this be fatal to the process?

>>  elf/dl-close.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/elf/dl-close.c b/elf/dl-close.c
>> index 73b2817bbf..896e59e42e 100644
>> --- a/elf/dl-close.c
>> +++ b/elf/dl-close.c
>> @@ -782,7 +782,7 @@ _dl_close_worker (struct link_map *map, bool force)
>>      {
>>        struct link_map *head = ns->_ns_loaded;
>>        /* Do not call the functions for any auditing object.  */
>> -      if (head->l_auditing == 0)
>> +      if (head != NULL && head->l_auditing == 0)
>>  	{
>>  	  struct audit_ifaces *afct = GLRO(dl_audit);
>>  	  for (unsigned int cnt = 0; cnt < GLRO(dl_naudit); ++cnt)
>> 
>
> Use _dl_signal_error to indicate an internal error?

This *is* on the cleanup path after an error already happened.  This is
the backtrace I saw:

(gdb) bt
#0  _dl_close_worker (map=<optimized out>, force=force@entry=true)
    at dl-close.c:785
#1  0x00007fbe468d3eb3 in _dl_open (file=0x7ffde8ed3f30 "\253\003\aE\276\177", 
    mode=mode@entry=-1946157055, 
    caller_dlopen=caller_dlopen@entry=0x7fbe468c2330 <dl_main>, nsid=9, 
    nsid@entry=-1, argc=1, argv=<optimized out>, env=0x7ffde8ed4550)
    at dl-open.c:906
#2  0x00007fbe468c120e in dlmopen_doit (a=a@entry=0x7ffde8ed41e0) at rtld.c:660
#3  0x00007fbe468dbd5e in _dl_catch_exception (
    exception=exception@entry=0x7ffde8ed4120, 
    operate=operate@entry=0x7fbe468c11d0 <dlmopen_doit>, 
    args=args@entry=0x7ffde8ed41e0) at dl-error-skeleton.c:208
#4  0x00007fbe468dbe03 in _dl_catch_error (objname=objname@entry=0x7ffde8ed41d0, 
    errstring=errstring@entry=0x7ffde8ed41d8, 
    mallocedp=mallocedp@entry=0x7ffde8ed41cf, 
    operate=operate@entry=0x7fbe468c11d0 <dlmopen_doit>, 
    args=args@entry=0x7ffde8ed41e0) at dl-error-skeleton.c:227
#5  0x00007fbe468c48e4 in load_audit_module (last_audit=<synthetic pointer>, 
    name=0x7ffde8ed42b8 "tst-auditmanymod9.so") at rtld.c:973
#6  load_audit_modules (audit_list=0x7ffde8ed4220, main_map=<optimized out>)
    at rtld.c:1114
#7  dl_main (phdr=<optimized out>, phnum=<optimized out>, 
    user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1679
#8  0x00007fbe468da84b in _dl_sysdep_start (
    start_argptr=start_argptr@entry=0x7ffde8ed4520, 
    dl_main=dl_main@entry=0x7fbe468c2330 <dl_main>) at ../elf/dl-sysdep.c:252
#9  0x00007fbe468c1e81 in _dl_start_final (arg=0x7ffde8ed4520) at rtld.c:489
#10 _dl_start (arg=0x7ffde8ed4520) at rtld.c:582
#11 0x00007fbe468c1098 in _start ()
   from /home/fweimer/src/gnu/glibc/build/elf/ld-linux-x86-64.so.2

(gdb) print exception 
$1 = {objname = 0x7fbe450703ab "/home/fweimer/src/gnu/glibc/build/libc.so.6", 
  errstring = 0x7fbe45070380 "cannot allocate memory in static TLS block", 
  message_buffer = 0x0}

We cannot report another error at this point.

Thanks,
Florian