Bug 475899 - extensible filter having range operation crashes the server
Summary: extensible filter having range operation crashes the server
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Database - Indexes/Searches
Version: 1.1.3
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2008-12-10 23:37 UTC by Noriko Hosoi
Modified: 2015-01-04 23:35 UTC (History)
4 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:08:45 UTC


Attachments (Terms of Use)
cvs diff ldap/servers/slapd/operation.c.diff (827 bytes, patch)
2008-12-10 23:38 UTC, Noriko Hosoi
no flags Details | Diff
cvs commit message (597 bytes, text/plain)
2008-12-11 00:09 UTC, Noriko Hosoi
no flags Details
cvs diff ldap/servers/slapd/back-ldbm/filterindex.c (2.29 KB, patch)
2008-12-12 00:07 UTC, Noriko Hosoi
no flags Details | Diff
cvs commit message (724 bytes, text/plain)
2008-12-12 01:22 UTC, Noriko Hosoi
no flags Details
output from test ldapsearch (301.55 KB, text/plain)
2009-04-07 22:02 UTC, Michael Gregg
no flags Details

Description Noriko Hosoi 2008-12-10 23:37:03 UTC
Description of problem:
This command line crashes the server:
ldapsearch -b "dc=example,dc=com" "(ou:2.16.840.1.113730.3.3.2.46.1:=>= acc*)"

Stacktrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x435ab950 (LWP 29031)]
0x00000000006da9b4 in slapi_op_abandoned (pb=0xe6b0b0)
    at ldap/servers/slapd/operation.c:58
58              op_status = pb->pb_op->o_status;
(gdb) p pb->pb_op
$4 = (Operation *) 0x0
(gdb) bt
#0  0x00000000006da9b4 in slapi_op_abandoned (pb=0xe6b0b0)
    at ldap/servers/slapd/operation.c:58
#1  0x00007f7bbefb2747 in index_range_read (pb=0xe6b0b0, be=0xbbd970, 
    type=0xb10480 "ou", indextype=0xadcc00 "2.16.840.1.113730.3.3.2.46.1", 
    operator=4, val=0xdc16c0, nextval=0x0, range=0, txn=0x0, err=0x435a5c68)
    at ldap/servers/slapd/back-ldbm/index.c:1314
#2  0x00007f7bbef9e257 in extensible_candidates (glob_pb=0xe6d500, 
    be=0xbbd970, f=0xbd6b00, err=0x435a5c68)
    at ldap/servers/slapd/back-ldbm/filterindex.c:447
#3  0x00007f7bbef9d3d7 in filter_candidates (pb=0xe6d500, be=0xbbd970, 
    base=0xcac5c0 "dc=example,dc=com", f=0xbd6b00, nextf=0x0, range=0, 
    err=0x435a5c68) at ldap/servers/slapd/back-ldbm/filterindex.c:151
#4  0x00007f7bbef9ee39 in list_candidates (pb=0xe6d500, be=0xbbd970, 
    base=0xcac5c0 "dc=example,dc=com", flist=0xbd6da0, ftype=161, 
    err=0x435a5c68) at ldap/servers/slapd/back-ldbm/filterindex.c:733
#5  0x00007f7bbef9d493 in filter_candidates (pb=0xe6d500, be=0xbbd970, 
    base=0xcac5c0 "dc=example,dc=com", f=0xbd6da0, nextf=0x0, range=0, 
    err=0x435a5c68) at ldap/servers/slapd/back-ldbm/filterindex.c:161
#6  0x00007f7bbefcb885 in subtree_candidates (pb=0xe6d500, be=0xbbd970, 
    base=0xcac5c0 "dc=example,dc=com", e=0xcbc910, filter=0xbd6b00, 
    managedsait=0, allids_before_scopingp=0x435a5e0c, err=0x435a5c68)
    at ldap/servers/slapd/back-ldbm/ldbm_search.c:850
#7  0x00007f7bbefcb39f in build_candidate_list (pb=0xe6d500, be=0xbbd970, 
    e=0xcbc910, base=0xcac5c0 "dc=example,dc=com", scope=2, 
    lookup_returned_allidsp=0x435a5e0c, candidates=0x435a5db8)
    at ldap/servers/slapd/back-ldbm/ldbm_search.c:659
#8  0x00007f7bbefca9c3 in ldbm_back_search (pb=0xe6d500)
    at ldap/servers/slapd/back-ldbm/ldbm_search.c:416
#9  0x00000000006dc259 in op_shared_search (pb=0xe6d500, send_result=1)
    at ldap/servers/slapd/opshared.c:547
#10 0x0000000000429816 in do_search (pb=0xe6d500)
    at ldap/servers/slapd/search.c:350
#11 0x0000000000412741 in connection_dispatch_operation (conn=0x7f7bbb09a610, 
    op=0xe6d830, pb=0xe6d500) at ldap/servers/slapd/connection.c:530
#12 0x0000000000413d18 in connection_threadmain ()
    at ldap/servers/slapd/connection.c:2161
#13 0x00000034e2829af3 in ?? () from /usr/lib64/libnspr4.so
#14 0x0000003c1d40729a in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#15 0x0000003c1c8e439d in clone () from /lib64/libc.so.6

Comment 1 Noriko Hosoi 2008-12-10 23:38:28 UTC
Created attachment 326559 [details]
cvs diff ldap/servers/slapd/operation.c.diff

Description: we should prevent accessing the inside of NULL pointer.

Comment 2 Noriko Hosoi 2008-12-11 00:09:12 UTC
Created attachment 326560 [details]
cvs commit message

Reviewed by Nathan (Thank you!!)

Checked in into CVS HEAD.

Comment 3 Rich Megginson 2008-12-11 22:35:36 UTC
So if op is NULL, op is abandoned will return 0 (false).  Under what conditions will op be NULL?  Is there any chance we would want to return op abandoned == true in those cases?  I think the fix is fine, I just want to understand a bit more about how this could happen and whether this fix will break anything else.

Comment 4 Noriko Hosoi 2008-12-11 22:55:29 UTC
(In reply to comment #3)
> So if op is NULL, op is abandoned will return 0 (false).  Under what conditions
> will op be NULL?  Is there any chance we would want to return op abandoned ==
> true in those cases?  I think the fix is fine, I just want to understand a bit
> more about how this could happen and whether this fix will break anything else.

extensible_candidates (flame #2) creates a temporary pblock in the function and pass it to index_range_read (flame #1), which does not have "op".  We could check if the operation is abandoned in extensible_candidates maybe before calling index_range_read using glob_pb which should have op.
#0  0x00000000006da9b4 in slapi_op_abandoned (pb=0xe6b0b0)
    at ldap/servers/slapd/operation.c:58
#1  0x00007f7bbefb2747 in index_range_read (pb=0xe6b0b0, be=0xbbd970, 
    type=0xb10480 "ou", indextype=0xadcc00 "2.16.840.1.113730.3.3.2.46.1", 
    operator=4, val=0xdc16c0, nextval=0x0, range=0, txn=0x0, err=0x435a5c68)
    at ldap/servers/slapd/back-ldbm/index.c:1314
#2  0x00007f7bbef9e257 in extensible_candidates (glob_pb=0xe6d500, 
    be=0xbbd970, f=0xbd6b00, err=0x435a5c68)
    at ldap/servers/slapd/back-ldbm/filterindex.c:447
#3  0x00007f7bbef9d3d7 in filter_candidates (pb=0xe6d500, be=0xbbd970, 
    base=0xcac5c0 "dc=example,dc=com", f=0xbd6b00, nextf=0x0, range=0, 
    err=0x435a5c68) at ldap/servers/slapd/back-ldbm/filterindex.c:151
    [...]

Comment 5 Rich Megginson 2008-12-11 23:09:33 UTC
I think we have to check glob_pb->op somehow in index_range_read() - the intention is to allow the client to cancel a long running operation with an abandon.  Would it be possible to set the temp pb->pb_op to glob_pb->pb_op?

Comment 6 Noriko Hosoi 2008-12-11 23:23:56 UTC
(In reply to comment #5)
> I think we have to check glob_pb->op somehow in index_range_read() - the
> intention is to allow the client to cancel a long running operation with an
> abandon.  Would it be possible to set the temp pb->pb_op to glob_pb->pb_op?

I think so.  But let me test it...

Comment 7 Noriko Hosoi 2008-12-12 00:07:25 UTC
Created attachment 326692 [details]
cvs diff ldap/servers/slapd/back-ldbm/filterindex.c

Description: As Rich suggested, set the pb->pb_op to glob_pb->pb_op to catch the abandon request in case the underlying operation is interrupted.

Valgrind reports no errors nor leaks.

Comment 8 Rich Megginson 2008-12-12 00:57:44 UTC
Excellent.

Comment 9 Noriko Hosoi 2008-12-12 01:22:49 UTC
Created attachment 326696 [details]
cvs commit message

Reviewed by Rich (Thank you!!!)

Checked in into CVS HEAD.

Comment 10 Michael Gregg 2009-04-07 22:01:34 UTC
results of ldapsearch -1 -h localhost -p 389 -D 'cn=directory manager' -w <pw> -b "dc=example,dc=com" "(ou:2.16.840.1.113730.3.3.2.46.1:=>= acc*)"
attached as file. 

No crashes.

closed as verified.

Comment 11 Michael Gregg 2009-04-07 22:02:47 UTC
Created attachment 338619 [details]
output from test ldapsearch

Comment 12 Chandrasekar Kannan 2009-04-29 23:08:45 UTC
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.

http://rhn.redhat.com/errata/RHEA-2009-0455.html


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