Bug 1370630 - glibc: nss_db: Endless loop in services database processing
Summary: glibc: nss_db: Endless loop in services database processing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: Sergey Kolosov
URL:
Whiteboard:
Depends On:
Blocks: 1390370 1388639
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)
Environment:
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


Links
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):
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 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.

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.