Bug 690526 - Double free in dse_add()
Double free in dse_add()
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.2.8
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 639035 389_1.2.8 690536
  Show dependency treegraph
 
Reported: 2011-03-24 11:14 EDT by Nathan Kinder
Modified: 2015-12-07 12:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 690536 (view as bug list)
Environment:
Last Closed: 2015-12-07 12:00:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for cov#10734 (2.19 KB, patch)
2011-03-24 11:18 EDT, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

  None (edit)
Description Nathan Kinder 2011-03-24 11:14:57 EDT
It's possible to encounter a double free of a Slapi_Entry in an error condition in dse_add().  This function makes a copy of the entry being added for use by postop plug-ins, but it can be free'd twice in the following code:

  e_copy = slapi_entry_dup(e);
  if ( dse_add_entry_pb(pdse, e_copy, pb) != 0)
  {
      slapi_send_ldap_result( pb, LDAP_OPERATIONS_ERROR, NULL, NULL, 0, NULL );
      slapi_sdn_done(&sdn);
      return dse_add_return(error, e_copy);
  }

The dse_add_entry_pb() function frees the passed in entry in all conditions, but dse_add_return() also free's the passed in entry.  This double free could trigger a crash.

The way dse_add works is that entry in SLAPI_ADD_ENTRY in the pblock should be consumed upon success, but will be left for the caller to deal with upon failure.  We should be passing NULL for the second argument to dse_add_return() to avoid the double free.
Comment 1 Nathan Kinder 2011-03-24 11:18:30 EDT
Created attachment 487370 [details]
Patch for cov#10734
Comment 2 Rich Megginson 2011-03-24 11:24:27 EDT
Do we need to get this in asap?
Comment 3 Nathan Kinder 2011-03-24 11:37:24 EDT
(In reply to comment #2)
> Do we need to get this in asap?

I don't know how easy it is to trigger this issue since it is in an error block when adding an entry to the dse backend, but it seems like we should try to get it in ASAP to me.
Comment 4 Nathan Kinder 2011-03-24 11:39:15 EDT
Pushed to master.  Thanks to Rich for his review!

Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.02 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   b41338f..1b22679  master -> master
Comment 5 Nathan Kinder 2011-03-24 11:43:42 EDT
Pushed to 389-ds-base-1.2.8 branch:

Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.02 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   e641e98..753c550  128-local -> 389-ds-base-1.2.8
Comment 6 Amita Sharma 2011-05-02 01:50:32 EDT
Rich has confirmed the issue is fixed.

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