[Bug nss/26825] New: dlopen failure isn't properly handled by __nss_lookup_function

[Bug nss/26825] New: dlopen failure isn't properly handled by __nss_lookup_function

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

            Bug ID: 26825
           Summary: dlopen failure isn't properly handled by
                    __nss_lookup_function
           Product: glibc
           Version: 2.33
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nss
          Assignee: unassigned at sourceware dot org
          Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Fedora 33, CET feature was removed om /lib64/libnss_sss.so.2 by accident.
On Tiger Lake machine with

passwd:     sss files systemd

in /etc/nsswitch.conf, CET enabled nptl/tst-setuid1-static crashed
mysteriously:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f8c9243fba4 in __GI___nss_readline (poffset=<optimized out>, 
    len=<optimized out>, buf=<optimized out>, fp=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
    at ../include/ctype.h:41
41        return __libc_tsd_address (const uint16_t *, CTYPE_B);
(gdb) bt
#0  0x00007f8c9243fba4 in __GI___nss_readline (poffset=<optimized out>, 
    len=<optimized out>, buf=<optimized out>, fp=<optimized out>)
    at ../include/ctype.h:41
#1  __GI___nss_readline (fp=0x7f8c921f22a0, 
    buf=0x6f88d0 "root:x:0:0:root:/root:/bin/bash\n", len=<optimized out>, 
    poffset=0x7ffe2890e0e8) at nss_readline.c:26
#2  0x00007f8c924e94df in internal_getent (stream=stream@entry=0x7f8c921f22a0, 
    result=result@entry=0x4f34c0 <resbuf>, 
    buffer=buffer@entry=0x6f88d0 "root:x:0:0:root:/root:/bin/bash\n", 
    buflen=buflen@entry=1024, errnop=errnop@entry=0x6f7378)
    at nss_files/files-XXX.c:152
#3  0x00007f8c924e978c in _nss_files_getpwnam_r (name=0x4b6102 "nobody", 
    result=0x4f34c0 <resbuf>, 
    buffer=0x6f88d0 "root:x:0:0:root:/root:/bin/bash\n", buflen=1024, 
    errnop=0x6f7378) at nss_files/files-pwd.c:35
#4  0x0000000000450981 in __getpwnam_r (name=0x4b6102 "nobody", 
    resbuf=0x4f34c0 <resbuf>, 
    buffer=0x6f88d0 "root:x:0:0:root:/root:/bin/bash\n", buflen=1024, 
    result=<optimized out>) at ../nss/getXXbyYY_r.c:315
#5  0x0000000000450750 in getpwnam (name=0x4b6102 "nobody")
    at ../nss/getXXbyYY.c:134
#6  0x0000000000403174 in do_test () at tst-setuid1.c:1029
#7  legacy_test_function (argc=<optimized out>, argv=<optimized out>)
    at ../test-skeleton.c:56
#8  0x0000000000403d1f in support_test_main (argc=1, argv=0x7ffe2890e480, 
    config=0x7ffe2890e2c0) at support_test_main.c:402
#9  0x00000000004019f9 in main (argc=<optimized out>, argv=<optimized out>)
    at ../support/test-driver.c:168
(gdb) disass
Dump of assembler code for function __GI___nss_readline:
   0x00007f8c9243fb30 <+0>:     endbr64 
   0x00007f8c9243fb34 <+4>:     push   %r15
   0x00007f8c9243fb36 <+6>:     mov    %rdi,%r15
   0x00007f8c9243fb39 <+9>:     push   %r14
   0x00007f8c9243fb3b <+11>:    mov    %rsi,%r14
   0x00007f8c9243fb3e <+14>:    push   %r13
   0x00007f8c9243fb40 <+16>:    mov    %edx,%r13d
   0x00007f8c9243fb43 <+19>:    push   %r12
   0x00007f8c9243fb45 <+21>:    lea    -0x1(%rsi,%rdx,1),%r12
   0x00007f8c9243fb4a <+26>:    push   %rbp
   0x00007f8c9243fb4b <+27>:    push   %rbx
   0x00007f8c9243fb4c <+28>:    mov    %rcx,%rbx
   0x00007f8c9243fb4f <+31>:    sub    $0x8,%rsp
   0x00007f8c9243fb53 <+35>:    cmp    $0x2,%rdx
   0x00007f8c9243fb57 <+39>:    jbe    0x7f8c9243fc00 <__GI___nss_readline+208>
   0x00007f8c9243fb5d <+45>:    mov    %r15,%rdi
   0x00007f8c9243fb60 <+48>:    callq  0x7f8c9239d520 <__GI___ftello>
   0x00007f8c9243fb65 <+53>:    mov    %r15,%rdx
   0x00007f8c9243fb68 <+56>:    mov    %r13d,%esi
   0x00007f8c9243fb6b <+59>:    mov    %r14,%rdi
   0x00007f8c9243fb6e <+62>:    mov    %rax,(%rbx)
   0x00007f8c9243fb71 <+65>:    movb   $0xff,(%r12)
   0x00007f8c9243fb76 <+70>:    callq  0x7f8c9239e910 <__GI___fgets_unlocked>
   0x00007f8c9243fb7b <+75>:    test   %rax,%rax
   0x00007f8c9243fb7e <+78>:    je     0x7f8c9243fc1d <__GI___nss_readline+237>
   0x00007f8c9243fb84 <+84>:    cmpb   $0xff,(%r12)
   0x00007f8c9243fb89 <+89>:    jne    0x7f8c9243fc43 <__GI___nss_readline+275>
   0x00007f8c9243fb8f <+95>:    mov    0x9c23a(%rip),%rax        #
0x7f8c924dbdd0
   0x00007f8c9243fb96 <+102>:   movsbq (%r14),%rdx
   0x00007f8c9243fb9a <+106>:   mov    %r14,%rbp
   0x00007f8c9243fb9d <+109>:   mov    %fs:(%rax),%rcx
   0x00007f8c9243fba1 <+113>:   mov    %rdx,%rax
=> 0x00007f8c9243fba4 <+116>:   testb  $0x20,0x1(%rcx,%rdx,2)
   0x00007f8c9243fba9 <+121>:   je     0x7f8c9243fbc3 <__GI___nss_readline+147>
   0x00007f8c9243fbab <+123>:   nopl   0x0(%rax,%rax,1)
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) p $rcx
$1 = 0
(gdb) 

__nss_lookup_function in nss/nsswitch.c has

         /* Load the appropriate library.  */
          if (nss_load_library (ni) != 0)
            /* This only happens when out of memory.  */
            goto remove_from_tree;

nss_load_library returns NULL on /lib64/libnss_sss.so.2.  But cleanup is
done wrong in such a way that

extern __thread const uint16_t * __libc_tsd_CTYPE_B __attribute__ ((tls_model
("initial-exec")));

extern inline const uint16_t ** __attribute__ ((const))
__ctype_b_loc (void)
{
  return (&__libc_tsd_CTYPE_B);
}

crashes due to bad

        movq    __libc_tsd_CTYPE_B@gottpoff(%rip), %rax 
        movsbq  (%r14), %rdx 
        .loc 1 68 13 view .LVU25
        movq    %r14, %rbp 
        .loc 1 68 14 view .LVU26
        movq    %fs:(%rax), %rcx 
        movq    %rdx, %rax 
        .loc 1 68 13 view .LVU27
        testb   $32, 1(%rcx,%rdx,2)   <<< RCX is 0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I think the use of isspace in __nss_readline has to go.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Or maybe it's the unloading of libc.so.6 after static dlopen that triggers
this. We may avoid this by loading libc.so.6 separately, on the first dlopen
call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Florian Weimer from comment #2)
> Or maybe it's the unloading of libc.so.6 after static dlopen that triggers
> this. We may avoid this by loading libc.so.6 separately, on the first dlopen
> call.

Mark libc.so.6 with NODELETE?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #3)
> (In reply to Florian Weimer from comment #2)
> > Or maybe it's the unloading of libc.so.6 after static dlopen that triggers
> > this. We may avoid this by loading libc.so.6 separately, on the first dlopen
> > call.
> 
> Mark libc.so.6 with NODELETE?

It doesn't work.  libc.so.6 wasn't unloaded.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to H.J. Lu from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Florian Weimer from comment #2)
> > > Or maybe it's the unloading of libc.so.6 after static dlopen that triggers
> > > this. We may avoid this by loading libc.so.6 separately, on the first dlopen
> > > call.
> > 
> > Mark libc.so.6 with NODELETE?
> 
> It doesn't work.  libc.so.6 wasn't unloaded.

Yes, this is expected after the NODELETE changes. We need to debug this to
figure out where things go wrong, if we do not want to load libc.so.6 in a way
that makes load failure unlikely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Florian Weimer from comment #5)
> 
> Yes, this is expected after the NODELETE changes. We need to debug this to
> figure out where things go wrong, if we do not want to load libc.so.6 in a
> way that makes load failure unlikely.

In static executable, libc.so.6 was loaded by /lib64/libnss_sss.so.2.  When
dlopen of /lib64/libnss_sss.so.2 failed, libc.so.6 might be in the partially
loaded stage.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nss/26825] dlopen failure isn't properly handled by __nss_lookup_function

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26825

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
This may be another instance of PR 25396, only for static executables.

-- 
You are receiving this mail because:
You are on the CC list for the bug.