Bug 726352

Summary:	openldap is not calling the clear session cache function of NSS
Product:	Red Hat Enterprise Linux 6	Reporter:	Ondrej Moriš <omoris>
Component:	nss	Assignee:	Elio Maldonado Batiz <emaldona>
Status:	CLOSED WORKSFORME	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.1	CC:	amarecek, jplans, kengert, rrelyea, tsmetana
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-27 21:06:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Ondrej Moriš 2011-07-28 11:00:55 UTC

Description of problem:

Please see BZ#717738#c18-20. 

There is a possible leak in openldap (see below) while using ldapsearch over TLS. It has been suggested that this is a bug in openldap.

==5127== 32 bytes in 1 blocks are definitely lost in loss record 46 of 87
==5127==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==5127==    by 0xC13008: PR_Malloc (prmem.c:467)
==5127==    by 0xC0FBC1: GrowStuff (prprf.c:1076)
==5127==    by 0xC0F5E6: dosprintf (prprf.c:137)
==5127==    by 0xC0FA81: PR_vsmprintf (prprf.c:1127)
==5127==    by 0xC0FC74: PR_smprintf (prprf.c:1105)
==5127==    by 0x551C85: nss_MkConfigString (nssinit.c:205)
==5127==    by 0x551D7B: nss_Init (nssinit.c:597)
==5127==    by 0x552AD7: NSS_InitContext (nssinit.c:800)
==5127==    by 0x4052CCE: tlsm_deferred_ctx_init (tls_m.c:1600)
==5127==    by 0xC18FD0: PR_CallOnceWithArg (prinit.c:832)
==5127==    by 0x404FCAC: tlsm_session_new (tls_m.c:2308)
==5127==    by 0x404DCFB: alloc_handle (tls2.c:296)
==5127==    by 0x404DE8B: ldap_int_tls_connect (tls2.c:341)
==5127==    by 0x404E111: ldap_int_tls_start (tls2.c:833)
==5127==    by 0x404E29B: ldap_start_tls_s (tls2.c:939)
==5127==    by 0x8052F52: tool_conn_setup (common.c:1290)
==5127==    by 0x804DB80: main (ldapsearch.c:900)

Version-Release number of selected component (if applicable):

openldap-2.4.23-15.el6 and openldap-2.4.23-16.el6

How reproducible:

always

Comment 1 Jan Vcelak 2011-08-14 21:21:55 UTC

https://bugzilla.redhat.com/show_bug.cgi?id=717738#c20
> 
> > This is a leak in NSS - please file a bug against nss for this.
> 
> Looks like Openldap is not calling the clear session cache function.
> 
> bob

OpenLDAP calls SSL_ClearSessionCache. I have verified that. I believe this is really a NSS bug. Switching the component to "nss".

Comment 2 RHEL Program Management 2011-10-07 16:01:28 UTC

Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 4 Kai Engert (:kaie) (inactive account) 2013-04-27 21:06:12 UTC

The bug description should have included information on how to reproduce the leak.

All I can find is the hint in the referenced bug to use
  ldapsearch -ZZ

I've executed
  valgrind ldapsearch -ZZ

on a RHEL 6.4 system, and I get:

==3480== Memcheck, a memory error detector
==3480== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3480== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3480== Command: ldapsearch -ZZ
==3480== 
ldap_start_tls: Can't contact LDAP server (-1)
==3480== 
==3480== HEAP SUMMARY:
==3480==     in use at exit: 33,155 bytes in 9 blocks
==3480==   total heap usage: 97 allocs, 88 frees, 45,021 bytes allocated
==3480== 
==3480== LEAK SUMMARY:
==3480==    definitely lost: 0 bytes in 0 blocks
==3480==    indirectly lost: 0 bytes in 0 blocks
==3480==      possibly lost: 0 bytes in 0 blocks
==3480==    still reachable: 33,155 bytes in 9 blocks
==3480==         suppressed: 0 bytes in 0 blocks
==3480== Rerun with --leak-check=full to see details of leaked memory
==3480== 
==3480== For counts of detected and suppressed errors, rerun with: -v
==3480== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 10)


I conclude the leak has been fixed in the meantime, and I'm resolving this bug as WORKSFORME.

If you still can reproduce leaks, then please provide steps to reproduce.