Bug 475899
| Summary: | extensible filter having range operation crashes the server | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Noriko Hosoi <nhosoi> | ||||||||||||
| Component: | Database - Indexes/Searches | Assignee: | Noriko Hosoi <nhosoi> | ||||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||
| Priority: | low | ||||||||||||||
| Version: | 1.1.3 | CC: | benl, mgregg, nkinder, rmeggins | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | 8.1 | Doc Type: | Bug Fix | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2009-04-29 23:08:45 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: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 249650, 493682 | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 326559 [details]
cvs diff ldap/servers/slapd/operation.c.diff
Description: we should prevent accessing the inside of NULL pointer.
Created attachment 326560 [details]
cvs commit message
Reviewed by Nathan (Thank you!!)
Checked in into CVS HEAD.
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. (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 [...] 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? (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... 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.
Excellent. Created attachment 326696 [details]
cvs commit message
Reviewed by Rich (Thank you!!!)
Checked in into CVS HEAD.
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. Created attachment 338619 [details]
output from test ldapsearch
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 |
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