Bug 233382 - nss_ldap crashes on large groups (IA64)
nss_ldap crashes on large groups (IA64)
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
ia64 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Ondrej Moriš
Depends On:
Blocks: 246627
  Show dependency treegraph
Reported: 2007-03-21 18:42 EDT by Franco M. Bladilo
Modified: 2011-01-04 03:41 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2008-0715
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 15:55:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
nss_ldap-226-ber_free_buf.patch (516 bytes, patch)
2007-08-30 07:34 EDT, Jose Plans
no flags Details | Diff

  None (edit)
Description Franco M. Bladilo 2007-03-21 18:42:13 EDT
Description of problem:
Any application that performs a ldap lookup crashes/segfaults when a highly
populated group is accessed via nss_ldap on ia64 systems.
We assign every user in our clusters to a supplementary group called "users",
apparently this group has grown to a size that nss_ldap doesn't like anymore,
this is what we see now : 

[root@master3 users]# id bladilo
Segmentation fault
[root@master3 users]# 

These are the relevant syscall trace lines for the same command:

geteuid()                               = 0
gettimeofday({1174516009, 951700}, NULL) = 0
write(3, "0\201\247\2\1\16c\201\241\4(ou=rtc,ou=cluster,dc="..., 170) = 170
select(1024, [3], [], NULL, NULL)       = 1 (in [3])
read(3, "0\202\5\r\2\1\16d", 8)         = 8
read(3, "\202\5\6\4:cn=users,ou=Group,ou=rtc,ou"..., 1289) = 1289
select(1024, [3], [], NULL, NULL)       = 1 (in [3])
read(3, "0\f\2\1\16e\7\n", 8)           = 8
read(3, "\1\0\4\0\4\0", 6)              = 6
gettimeofday({1174516009, 953860}, NULL) = 0
gettimeofday({1174516009, 953998}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 2000000000139781 (c000000000021b60) ---
+++ killed by SIGSEGV +++
Process 25484 detached

Other commands also provide strange results/output : 
[root@master3 users]# ls -la
ls: ../../../libraries/liblber/io.c:171: ber_free_buf: Assertion
`((ber)->ber_opts.lbo_valid==0x2)' failed.

We downloaded and installed nss_ldap-255-1/pam_ldap-184 from padl's website in
one of our test boxes and this problem went away.
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Populate a ldap supplementary group with more than 150 entries
2. Bind to ldap with an ia64 RHEL4 (u4) client
3. Try running any command (id,ls,etc) that performs a supplementary group lookup. 
Actual results:

command crashes/segfaults

Expected results:

Additional info:
Comment 1 Jose Plans 2007-08-30 07:34:22 EDT
Created attachment 180761 [details]
Comment 4 Issue Tracker 2007-10-10 14:36:13 EDT
I downloaded the nss_ldap-226-18.it133168.x86_64.rpm package from
http://people.redhat.com/ichihi/.allianz/it133168/ and find that it fixes
the ber_free_buf error in the IBM test environment.

This event sent from IssueTracker by jwest 
 issue 130212
Comment 9 RHEL Product and Program Management 2007-11-28 23:21:22 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 14 errata-xmlrpc 2008-07-24 15:55:35 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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