Bug 2147595

The issue is even a bit worse, because it not only happens indirectly when calling `gethostbyname`, but also indirectly when calling `getpwuid_r` and similar. But again: it only crashes if NIS is consulted.

I've created another example program to demonstrate that: libnsl2crash2.c
After installing the debug symbols for libnsl2-2.0.0-4.fc37, I get a slightly better stack trace:

#0  0x0000000000000000 in ?? ()
#1  0x0000000000457e3d in __interceptor_xdrstdio_create.part.0 ()
#2  0x00007ffff75d9e43 in yp_bind_file (ysd=0x612000000340, domain=0x7ffff75de020 <ypdomainname> "XXXXXXXXXXXXXXXXXXX")
    at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:109
#3  __yp_bind (domain=domain@entry=0x7ffff75de020 <ypdomainname> "XXXXXXXXXXXXXXXXXXX", ypdb=ypdb@entry=0x7fffffffccd0)
    at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:275
#4  0x00007ffff75da24e in __yp_bind (ypdb=0x7fffffffccd0, domain=0x7ffff75de020 <ypdomainname> "XXXXXXXXXXXXXXXXXXX")
    at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:254
#5  do_ypcall (domain=0x7ffff75de020 <ypdomainname> "XXXXXXXXXXXXXXXXXXX", prog=prog@entry=3, xargs=xargs@entry=0x7ffff75d8ce0 <xdr_ypreq_key>, 
    req=req@entry=0x7fffffffcd40 " \340]\367\377\177", xres=xres@entry=0x7ffff75d8d50 <xdr_ypresp_val>, resp=resp@entry=0x7fffffffcd20 "")
    at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:442
#6  0x00007ffff75daae7 in do_ypcall_tr (resp=0x7fffffffcd20, xres=0x7ffff75d8d50 <xdr_ypresp_val>, req=0x7fffffffcd40 " \340]\367\377\177", 
    xargs=0x7ffff75d8ce0 <xdr_ypreq_key>, prog=3, domain=<optimized out>) at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:475
#7  yp_match (indomain=<optimized out>, inmap=<optimized out>, inkey=<optimized out>, inkeylen=<optimized out>, outval=0x7fffffffcdd0, outvallen=0x7fffffffcdc4)
    at /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/yp_match.c:48
#8  0x00007ffff790ae4b in _nss_nis_getpwuid_r () from /lib64/libnss_nis.so.2
#9  0x00007ffff7d85061 in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
#10 0x00000000004735ec in getpwuid_r ()
#11 0x0000000000515a3a in main (argc=2, argv=0x7fffffffd958) at libnsl2crash2.c:79

Created attachment 1927381 [details]
small test programm calling getpwuid_r

I think this needs an upstream report. Fedora is driving NIS(+) removal in Fedora 38, but this looks like nothing specific to Fedora.

Few more questions before that.

1. Is this reproducible with clang only or a gcc-built example fails as well?

2. The crash happens in xdrstdio_create() implementation. Fedora uses tirpc, and libnsl2 links against tirpc. May be it is actually a bug in tirpc?

The code in question in libnsl2 is this:

  FILE *in = fopen (path, "rce");
  if (in != NULL)
    {
....
      XDR xdrs;
      xdrstdio_create (&xdrs, in, XDR_DECODE);
....

E.g. it passes a file object to initialize XDR stream and the code crashes there in TIRPC code.

Thank Alexander for looking into this!

(In reply to Alexander Bokovoy from comment #3)
> I think this needs an upstream report. Fedora is driving NIS(+) removal in
> Fedora 38, but this looks like nothing specific to Fedora.
> 
> Few more questions before that.
> 
> 1. Is this reproducible with clang only or a gcc-built example fails as well?

It also crashes with gcc (I had to install package libasan first in order to try it out):

# sudo dnf info libasan
Installed Packages
Name         : libasan
Version      : 12.2.1
Release      : 4.fc37
Architecture : x86_64
Size         : 1.3 M
Source       : gcc-12.2.1-4.fc37.src.rpm
[..]

This is the ASAN stacktrace from running the gcc sanitized example "libnslcrash2.c" (2nd example):

# gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
[..]

# gcc -g -fno-optimize-sibling-calls -fsanitize=address -fno-omit-frame-pointer libnsl2crash2.c 
# ./a.out 1076
getpwuid_r(1076) ... AddressSanitizer:DEADLYSIGNAL
=================================================================
==1413854==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ffd597ebe70 sp 0x7ffd597eb618 T0)
==1413854==Hint: pc points to the zero page.
==1413854==The signal is caused by a READ memory access.
==1413854==Hint: address points to the zero page.
    #0 0x0  (<unknown module>)
    #1 0x7fc2eb8cfe42 in yp_bind_file /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:109
    #2 0x7fc2eb8cfe42 in __yp_bind /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:275
    #3 0x7fc2eb8d024d in __yp_bind /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:254
    #4 0x7fc2eb8d024d in do_ypcall /usr/src/debug/libnsl2-2.0.0-4.fc37.x86_64/src/do_ypcall.c:442

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>) 
==1413854==ABORTING

It seems like the stack trace is identical. The last frame is suspicious, though. Perhaps the stack is smashed/garbled.


> 2. The crash happens in xdrstdio_create() implementation. Fedora uses tirpc,
> and libnsl2 links against tirpc. May be it is actually a bug in tirpc?

That could very well be, because the last stack frame is unknown.
The libtirpc version in use is:
# sudo dnf info libtirpc
Installed Packages
Name         : libtirpc
Version      : 1.3.3
Release      : 0.fc37
Architecture : i686
Size         : 218 k
Source       : libtirpc-1.3.3-0.fc37.src.rpm
[...]


Would be cool, if someone except myself is able to reproduce any of these issues.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.