Bug 784203 - Duplicate close() calls in OpenLDAP
Duplicate close() calls in OpenLDAP
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap (Show other bugs)
6.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Jan Vcelak
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-24 03:55 EST by Peter Klotz
Modified: 2013-03-03 20:29 EST (History)
4 users (show)

See Also:
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 03:29:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Invalid sockets fix (1.31 KB, patch)
2012-02-03 07:40 EST, Jan Synacek
no flags Details | Diff

  None (edit)
Description Peter Klotz 2012-01-24 03:55:52 EST
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 05:30:21 EST
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 07:40:05 EST
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 07:41:38 EST
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 05:47:11 EST
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 06:03:48 EST
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 06:34:55 EST
Hello Peter,

Here they are.
http://jsynacek.fedorapeople.org/openldap/x86_64/
Comment 8 Peter Klotz 2012-02-09 06:55:53 EST
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 05:01:25 EST
(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 06:07:25 EST
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 07:56:37 EST
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 06:20:00 EST
    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 11:18:26 EST
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 11:24:10 EST
    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 03:29:18 EDT
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

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