RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1370630 - glibc: nss_db: Endless loop in services database processing
Summary: glibc: nss_db: Endless loop in services database processing
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: Sergey Kolosov
Depends On:
Blocks: 1388639 1390370
TreeView+ depends on / blocked
Reported: 2016-08-26 20:24 UTC by Frank Hirtz
Modified: 2020-04-15 14:38 UTC (History)
9 users (show)

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.
Clone Of:
: 1388639 (view as bug list)
Last Closed: 2017-08-01 18:09:25 UTC
Target Upstream Version:

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

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1213603 0 urgent CLOSED glibc: nss_db: get*ent crashes without preceding set*ent 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1318890 0 urgent CLOSED glibc: nss_db: long group entries are skipped 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2017:1916 0 normal SHIPPED_LIVE Moderate: glibc security, bug fix, and enhancement update 2017-08-01 18:05:43 UTC
Sourceware 14498 0 P2 RESOLVED default /var/db/services.db triggers infinite CPU loop with getaddrinfo() 2020-12-02 16:21:03 UTC

Internal Links: 1213603 1318890

Description Frank Hirtz 2016-08-26 20:24:23 UTC
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):

How reproducible:

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

For info:
[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

[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

Expected results:

Additional info:
I did a test build with the upstream patch from:


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 18:09:25 UTC
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.


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