Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1370630 - glibc: nss_db: Endless loop in services database processing
glibc: nss_db: Endless loop in services database processing
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc (Show other bugs)
7.2
All Linux
high Severity high
: rc
: ---
Assigned To: Florian Weimer
Sergey Kolosov
: Patch, ZStream
Depends On:
Blocks: 1390370 1388639
  Show dependency treegraph
 
Reported: 2016-08-26 16:24 EDT by Frank Hirtz
Modified: 2017-08-01 14:09 EDT (History)
9 users (show)

See Also:
Fixed In Version: glibc-2.17-158.el7
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 1388639 (view as bug list)
Environment:
Last Closed: 2017-08-01 14:09:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Quick test patch (1.88 KB, patch)
2016-08-26 16:24 EDT, Frank Hirtz
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 14498 None None None 2016-09-01 04:06 EDT
Red Hat Product Errata RHSA-2017:1916 normal SHIPPED_LIVE Moderate: glibc security, bug fix, and enhancement update 2017-08-01 14:05:43 EDT

  None (edit)
Description Frank Hirtz 2016-08-26 16:24:23 EDT
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.
Comment 14 errata-xmlrpc 2017-08-01 14:09:25 EDT
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

Note You need to log in before you can comment on or make changes to this bug.