Cause: The nss_db Name Service Switch module does not properly handle a protocol mismatch during lookups in the service database.
Consequence: Lookups in the service database can enter an infinite loop.
Fix: The nss_db code which looks up service entries has been fixed to deal with protocol mismatches and proceed with the next entry.
Result: Service entries can be found properly, without a hang.
Created attachment 1194457[details]
Quick test patch
Description of problem:
A client when working with RHEL7 to validate it for their environment found that they had processes getting stuck due to getaddrinfo() calls spinning.
Version-Release number of selected component (if applicable):
glibc-2.17-106.el7_2.8
How reproducible:
Always
Steps to Reproduce:
1. Enable the use of 'db' files in nsswitch
2. Make 'db' files
3. Run something that does a query, say 'rpcinfo -p localhost'
Actual results:
[root@ivanova ~]# grep services /etc/nsswitch.conf | grep -v '^#'
services: db files sss
[root@ivanova ~]# cd /var/db/
[root@ivanova db]# make
services... done.
[root@ivanova db]# rpcinfo -p localhost
<hang>
For info:
<strace>
[root@ivanova db]# strace rpcinfo -p localhost
....
read(3, "rt\nsafetynetp 40000/tcp "..., 4096) = 4096
read(3, " 45678/tcp # EBA"..., 4096) = 2645
read(3, "", 4096) = 0
close(3) = 0
munmap(0x7f08ae571000, 4096) = 0
open("/var/db/services.db", O_RDONLY|O_CLOEXEC) = 3
read(3, "\1\6\21\335\2\0\0\0`\0\0\0\0\0\0\0\304I\4\0\0\0\0\0\334\177\10\0\0\0\0\0", 32) = 32
mmap(NULL, 557020, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f08ae4d6000
close(3)
<hang>
</strace>
<ltrace>
[root@ivanova db]# ltrace rpcinfo -p localhost
[root@ivanova db]# ltrace rpcinfo -p localhost
__libc_start_main(0x7fc84409a830, 3, 0x7fff23af8608, 0x7fc84409dab0 <unfinished ...>
getopt(3, 0x7fff23af8608, "a:bdlmn:pstT:u") = 112
getopt(3, 0x7fff23af8608, "a:bdlmn:pstT:u") = -1
inet_addr("localhost") = 0xffffffff
__rpc_getconfip(0x7fc84409e27e, 0x7fff23af96fa, 0xffffffffffffc817, 0) = 0x7fc84534e440
getaddrinfo("localhost", "rpcbind", 0x7fff23af8350, 0x7fff23af8348
<hang>
</ltrace>
Expected results:
Works.
Additional info:
I did a test build with the upstream patch from:
https://sourceware.org/bugzilla/show_bug.cgi?id=14498
Included and the operation worked properly. The client who reported this (with their own maps, not the default that I'm using) ran their internal tests with the patched build and their issue was cleared up as well.
The quick patch that I used is attached for reference, though it's just a copy of the upstream diff applied to our tree.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2017:1916