Logged in as guest
Viewing Software Bugs/7431 Full headers
Major security issue: yes no
Notes: fixed in master fixed in RE24 Notification:
Date: Sun, 04 Nov 2012 16:33:22 +0000 From: michael@stroeder.com To: openldap-its@OpenLDAP.org Subject: seg fault in constraint_check_restrict at constraint.c:713
Full_Name: Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 OS: openSUSE 12.2 x86_64 URL: Submission from: (NULL) (79.227.185.139) I get a seg fault when adding group entries with some regex-constrained attributes. This is RE24 with the recent fixes for slapo-constraint. The constraint setup works with 2.4.31. Strange thing is that the entry is added to the database. So it seems to me that the seg fault happens after that while checking constraints for what slapo-memberof does? As often this is a complex customer setup. So it's not that easy to narrow down the config and strip aways private customer data in a full traceback. I will do if really necessary. Maybe this gives a first hint where to look: No symbol "info" in current context. (gdb) info threads Id Target Id Frame 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () from /lib64/libc.so.6 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () from /lib64/libpthread.so.0 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at constraint.c:713
Date: Sun, 04 Nov 2012 17:48:12 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: openldap-its@OpenLDAP.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
It works when using constraint.c of OpenLDAP release 2.4.32.
Date: Sun, 04 Nov 2012 17:58:13 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: openldap-its@OpenLDAP.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
It also works when using constraint.c of OpenLDAP release 2.4.33. Maybe it's caused by fix for ITS#7418?
Date: Mon, 05 Nov 2012 12:00:21 +0100 From: Jan Synacek <jsynacek@redhat.com> To: michael@stroeder.com CC: openldap-its@OpenLDAP.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
On 11/04/2012 05:33 PM, michael@stroeder.com wrote: > Full_Name: > Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 > OS: openSUSE 12.2 x86_64 > URL: > Submission from: (NULL) (79.227.185.139) > > > I get a seg fault when adding group entries with some regex-constrained > attributes. This is RE24 with the recent fixes for slapo-constraint. The > constraint setup works with 2.4.31. > > Strange thing is that the entry is added to the database. So it seems to me that > the seg fault happens after that while checking constraints for what > slapo-memberof does? > > As often this is a complex customer setup. So it's not that easy to narrow down > the config and strip aways private customer data in a full traceback. I will do > if really necessary. > > Maybe this gives a first hint where to look: > > No symbol "info" in current context. > (gdb) info threads > Id Target Id Frame > 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () > from /lib64/libc.so.6 > 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () > from /lib64/libpthread.so.0 > 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in > constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at > constraint.c:713 > Hello Michael, can you please provide a full backtrace of thread 1? A quick look suggest that there's something wrong, because constraint_check_restrict probably should not be called with e=0x0, but I'm unable to tell anything else with such restricted information. Also, if the problem is in my fix, it should be fairly easily reproducible with just a few slapadds with the right data. Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat
Date: Thu, 08 Nov 2012 08:14:07 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: Jan Synacek <jsynacek@redhat.com> CC: openldap-its@OpenLDAP.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
FYI: I sent output of bt full to Jan with some data stripped because of privacy concerns. Note that the entry for which constraint checking is done is added to the database. So something might be wrong *after* the check. Ciao, Michael.
Date: Thu, 08 Nov 2012 14:22:41 +0100 From: Jan Synacek <jsynacek@redhat.com> To: michael@stroeder.com CC: openldap-its@openldap.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
This is a multi-part message in MIME format. --------------000604070905040801090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/2012 08:14 AM, michael@stroeder.com wrote: > FYI: I sent output of bt full to Jan with some data stripped because of > privacy concerns. > > Note that the entry for which constraint checking is done is added to the > database. So something might be wrong *after* the check. > > Ciao, Michael. > > Can you please try the attached patch? If it doesn't fix the issue (or breaks something else that I'm not aware of) I will need a reproducer config and data. Thank you, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat --------------000604070905040801090708 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index ee8911b..f2c645c 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -935,10 +935,6 @@ constraint_update( Operation *op, SlapReply *rs ) /* Do we need to count attributes? */ for(cp = c; cp; cp = cp->ap_next) { - if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { - continue; - } - if (cp->count != 0) { if (rc != 0 || target_entry == NULL) { Debug(LDAP_DEBUG_TRACE, @@ -950,6 +946,10 @@ constraint_update( Operation *op, SlapReply *rs ) goto mod_violation; } + if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { + continue; + } + is_v = constraint_check_count_violation(m, target_entry, cp); Debug(LDAP_DEBUG_TRACE, --------------000604070905040801090708--
Date: Thu, 08 Nov 2012 21:29:22 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: Jan Synacek <jsynacek@redhat.com> CC: openldap-its@openldap.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
Jan Synacek wrote: > On 11/08/2012 08:14 AM, michael@stroeder.com wrote: >> FYI: I sent output of bt full to Jan with some data stripped because of >> privacy concerns. >> >> Note that the entry for which constraint checking is done is added to the >> database. So something might be wrong *after* the check. > > Can you please try the attached patch? It seems to work. But I will test it during the next days more thoroughly. Ciao, Michael.
Date: Wed, 14 Nov 2012 23:18:51 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: Jan Synacek <jsynacek@redhat.com> CC: openldap-its@openldap.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
Michael Str.der wrote: > Jan Synacek wrote: >> On 11/08/2012 08:14 AM, michael@stroeder.com wrote: >>> FYI: I sent output of bt full to Jan with some data stripped because of >>> privacy concerns. >>> >>> Note that the entry for which constraint checking is done is added to the >>> database. So something might be wrong *after* the check. >> >> Can you please try the attached patch? > > It seems to work. But I will test it during the next days more thoroughly. No more seg faults so far in my setup which uses slapo-constraints quite heavily. So I'd appreciate if Jan's patch lands in RE24 branch. Ciao, Michael.
Date: Sat, 24 Nov 2012 19:38:36 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> To: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com> CC: Jan Synacek <jsynacek@redhat.com>, openldap-its@openldap.org Subject: Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
This is a cryptographically signed message in MIME format. --------------ms010608050607040608060204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Str=F6der wrote: > Michael Str=F6der wrote: >> Jan Synacek wrote: >>> On 11/08/2012 08:14 AM, michael@stroeder.com wrote: >>>> FYI: I sent output of bt full to Jan with some data stripped because= of >>>> privacy concerns. >>>> >>>> Note that the entry for which constraint checking is done is added t= o the >>>> database. So something might be wrong *after* the check. >>> >>> Can you please try the attached patch? >> >> It seems to work. But I will test it during the next days more thoroug= hly. >=20 > No more seg faults so far in my setup which uses slapo-constraints quit= e > heavily. So I'd appreciate if Jan's patch lands in RE24 branch. What's the status of this? Is a more formal submission of Jan's patch needed to get this in? Ciao, Michael. --------------ms010608050607040608060204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvv
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
