Bug 784203

Summary: Duplicate close() calls in OpenLDAP
Product: Red Hat Enterprise Linux 6 Reporter: Peter Klotz <peter.klotz>
Component: openldapAssignee: Jan Vcelak <jvcelak>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: dspurek, jsynacek, ksrot, tsmetana
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openldap-2.4.23-21.el6 Doc Type: Bug Fix
Doc Text:
- in certain conditions, when unbind operation is called and the ldap handle is being destroyed - the library closes the connection socket when it is already closed, valgrind warnings are present - upstream patch applied which adds additional checks before closing the connection socket - the connection socket is closed only once, valgrind warnings are no longer present
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 07:29:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Invalid sockets fix none

Description Peter Klotz 2012-01-24 08:55:52 UTC
Description of problem:
In one of our regression tests valgrind complains about close() calls with argument -1 by OpenLDAP 2.4.23-20.el6.x86_64.

==1000== Warning: invalid file descriptor -1 in syscall close()

Calls to ldap_unbind_s() trigger this message.

This problem does not occur in RHEL5 (OpenLDAP 2.3.43-12.el5.x86_64).


Version-Release number of selected component (if applicable):
OpenLDAP 2.4.23-20.el6.x86_64

How reproducible:
Always

This link indicates that the problem is fixed in OpenLDAP 2.4.24:

http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6585;selectid=6585

See also the changelog (http://www.openldap.org/software/release/changes.html): 

Fixed liblber to not close invalid sockets (ITS#6585)


I suggest an update of OpenLDAP in RHEL6 to at least 2.4.24 (current is 2.4.28). If this is not an option, maybe the fix can be backported.

Comment 2 Karel Srot 2012-02-01 10:30:21 UTC
Hi Peter,
could you please share more details about your test setup & scenario that produces that valgrind warning? I didn't find much info in the upstream bug. 
Thank you in advance.

Comment 3 Jan Synacek 2012-02-03 12:40:05 UTC
Created attachment 559283 [details]
Invalid sockets fix

I dug out the patch that should fix this. It's applicable to releases -20 and -21 without any modification.

Comment 4 Jan Synacek 2012-02-03 12:41:38 UTC
Not sure how to reproduce the issue though. Running slapd in debug mode plus simple ldapsearch doesn't do the trick for me.

Comment 5 Jan Synacek 2012-02-09 10:47:11 UTC
Peter,
I've built new packages (potentionally without the problem you've mentioned). I wasn't able to reproduce the issue, so I would like to ask you to test them.
You can find them here: http://jsynacek.fedorapeople.org/openldap/.

Comment 6 Peter Klotz 2012-02-09 11:03:48 UTC
Hello Jan

Thanks a lot for integrating the fix. Could you also build x86_64 RPMs?

Our development environment only supports 64Bit binaries for compiling and testing.

Regards, Peter.

Comment 7 Jan Synacek 2012-02-09 11:34:55 UTC
Hello Peter,

Here they are.
http://jsynacek.fedorapeople.org/openldap/x86_64/

Comment 8 Peter Klotz 2012-02-09 11:55:53 UTC
Hello Jan

Your OpenLDAP "2.4.23-21" packages do the job. The problem is fixed and valgrind no longer complains.

Thank you very much for your efforts!

Will this change be part of RHEL 6.3?

Comment 9 Eduard Benes 2012-02-13 10:01:25 UTC
(In reply to comment #8)
> Hello Jan
> 
> Your OpenLDAP "2.4.23-21" packages do the job. The problem is fixed and
> valgrind no longer complains.
> 
> Thank you very much for your efforts!
> 
> Will this change be part of RHEL 6.3?

Peter, could you please share the steps how did you verify the fix? Thanks in advance!

Comment 10 Peter Klotz 2012-02-13 11:07:25 UTC
One of our daily executed internal regression tests showed the close() message when executed with valgrind.

I tracked the problem down to a ldap_unbind_ext_s() call in a destructor which meant the bug had to be in OpenLDAP.

In order to verify that the fix works, I upgraded all OpenLDAP packages on one of our build servers and executed the test manually.

Comment 11 Karel Srot 2012-02-15 12:56:37 UTC
Hi Peter,
could you please be more specific? What is your regression test doing? We won't be able to reproduce this bug without more detailed instructions.

Comment 16 Jan Synacek 2012-03-01 11:20:00 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- unknown (tests done by the reporter)
- consequences are seen only when the openldap server is run via special environment (valgrind)
- patch that fixes closing of invalid sockets was applied
- no valgrind warnings complaining about invalid sockets are present

Comment 17 Jan Vcelak 2012-03-01 16:18:26 UTC
Canceling needinfo. It can be reproduced very easily:

#!/usr/bin/python
import ldap
conn = ldap.initialize("ldap://localhost")
conn.simple_bind_s()
conn.unbind_s()

Old version (notice the warning):

==1487== Memcheck, a memory error detector
==1487== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1487== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==1487== Command: ./reproducer.py
==1487== 
==1487== Warning: invalid file descriptor -1 in syscall close()
==1487== 
==1487== HEAP SUMMARY:
==1487==     in use at exit: 1,064,304 bytes in 6,306 blocks
==1487==   total heap usage: 32,716 allocs, 26,410 frees, 7,109,607 bytes allocated
==1487== 
==1487== LEAK SUMMARY:
==1487==    definitely lost: 0 bytes in 0 blocks
==1487==    indirectly lost: 0 bytes in 0 blocks
==1487==      possibly lost: 14,928 bytes in 32 blocks
==1487==    still reachable: 1,049,376 bytes in 6,274 blocks
==1487==         suppressed: 0 bytes in 0 blocks
==1487== Rerun with --leak-check=full to see details of leaked memory
==1487== 
==1487== For counts of detected and suppressed errors, rerun with: -v
==1487== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 78 from 9)

Fixed version:

==1551== Memcheck, a memory error detector
==1551== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1551== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==1551== Command: ./reproducer.py
==1551== 
==1551== 
==1551== HEAP SUMMARY:
==1551==     in use at exit: 1,064,352 bytes in 6,306 blocks
==1551==   total heap usage: 32,716 allocs, 26,410 frees, 7,109,655 bytes allocated
==1551== 
==1551== LEAK SUMMARY:
==1551==    definitely lost: 0 bytes in 0 blocks
==1551==    indirectly lost: 0 bytes in 0 blocks
==1551==      possibly lost: 14,928 bytes in 32 blocks
==1551==    still reachable: 1,049,424 bytes in 6,274 blocks
==1551==         suppressed: 0 bytes in 0 blocks
==1551== Rerun with --leak-check=full to see details of leaked memory
==1551== 
==1551== For counts of detected and suppressed errors, rerun with: -v
==1551== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 79 from 9)

Comment 18 Jan Vcelak 2012-03-01 16:24:10 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
-- unknown (tests done by the reporter)
+- in certain conditions, when unbind operation is called and the ldap handle is being destroyed
-- consequences are seen only when the openldap server is run via special environment (valgrind)
+- the library closes the connection socket when it is already closed, valgrind warnings are present
-- patch that fixes closing of invalid sockets was applied
+- upstream patch applied which adds additional checks before closing the connection socket
-- no valgrind warnings complaining about invalid sockets are present+- the connection socket is closed only once, valgrind warnings are no longer present

Comment 21 errata-xmlrpc 2012-06-20 07:29:18 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.

http://rhn.redhat.com/errata/RHSA-2012-0899.html