[31055] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Race condition in /ccache/cc_memory.c

daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Mon May 4 10:01:00 2009

X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <49FEF4DF.5080205@secure-endpoints.com>
Date: Mon, 04 May 2009 09:59:59 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: hy93@cornell.edu
In-Reply-To: <49FAE5ED.9010504@cornell.edu>
Cc: kerberos@mit.edu
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1482063125=="
Errors-To: kerberos-bounces@mit.edu

This is a cryptographically signed message in MIME format.

--===============1482063125==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms040007060705090204090601"

This is a cryptographically signed message in MIME format.

--------------ms040007060705090204090601
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The fix for this problem is not in KFW 3.2.2.  
It was not pulled up to the 1.6 branch until 21 July 2008.
MIT has not issued a new version of the KFW libraries containing this fix.

Jeffrey Altman


Hong Ye wrote:
> When our application crashed, Call stack of one thread
>     krb5_32.dll!krb5_mcc_free(_krb5_context * context=0x023d87e0,
> _krb5_ccache * id=0x023d73e8)  Line 170 + 0x3 bytes    C
>     krb5_32.dll!krb5_mcc_destroy(_krb5_context * context=0x023d87e0,
> _krb5_ccache * id=0x023d73e8)  Line 208 + 0xb bytes    C
>     krb5_32.dll!krb5_cc_destroy(_krb5_context * context=0x023d87e0,
> _krb5_ccache * cache=0x023d73e8)  Line 56    C
>
> Call stack of another thread
>     krb5_32.dll!k5_os_mutex_lock(k5_os_mutex * m=0x01db3d7c)  Line 653
> + 0xd bytes    C
>     krb5_32.dll!k5_mutex_lock_1(k5_mutex_t * m=0x01db3d6c,
> k5_debug_loc l={...})  Line 733 + 0xc bytes    C
>     krb5_32.dll!profile_node_iterator(void * * iter_p=0x0124f4fc,
> profile_node * * ret_node=0x00000000, char * * ret_name=0x00000000,
> char * * ret_value=0x0124f4f8)  Line 470 + 0x29 bytes    C
>     krb5_32.dll!profile_get_value(_profile_t * profile=0x0243baa8,
> const char * * names=0x0124f56c, const char * * ret_value=0x0124f580) 
> Line 184 + 0x11 bytes    C
>     krb5_32.dll!profile_get_integer(_profile_t * profile=0x0243baa8,
> const char * name=0x1c08599c, const char * subname=0x1c085928, const
> char * subsubname=0x00000000, int def_val=4, int *
> ret_int=0x0124f5f8)  Line 247 + 0x10 bytes    C
>     krb5_32.dll!init_common(_krb5_context * * context=0x0124f738,
> unsigned int secure=0, unsigned int kdc=0)  Line 236    C
>     krb5_32.dll!krb5_init_context(_krb5_context * *
> context=0x0124f738)  Line 88 + 0xc bytes    C
>     gssapi32.dll!krb5_gss_init_context(_krb5_context * *
> ctxp=0x0124f738)  Line 1002    C
>     gssapi32.dll!krb5_gss_display_name(unsigned int *
> minor_status=0x0124f914, gss_name_struct * input_name=0x0243a900,
> gss_buffer_desc_struct * output_name_buffer=0x0124f8f4,
> gss_OID_desc_struct * * output_name_type=0x0124f904)  Line 37 + 0x9
> bytes    C
>     gssapi32.dll!k5glue_display_name(void * ctx=0x00000000, unsigned
> int * minor_status=0x0124f914, gss_name_struct *
> input_name=0x0243a900, gss_buffer_desc_struct *
> output_name_buffer=0x0124f8f4, gss_OID_desc_struct * *
> output_name_type=0x0124f904)  Line 564 + 0x11 bytes    C
>     gssapi32.dll!gssint_display_internal_name(unsigned int *
> minor_status=0x0124f914, gss_OID_desc_struct * mech_type=0x0243c0b0,
> gss_name_struct * internal_name=0x0243a900, gss_buffer_desc_struct *
> external_name=0x0124f8f4, gss_OID_desc_struct * *
> name_type=0x0124f904)  Line 418 + 0x18 bytes    C
>     gssapi32.dll!gss_display_name(unsigned int *
> minor_status=0x0124f914, gss_name_struct * input_name=0x0243a820,
> gss_buffer_desc_struct * output_name_buffer=0x0124f8f4,
> gss_OID_desc_struct * * output_name_type=0x0124f904)  Line 103 + 0x1a
> bytes    C
>
> Jeffrey Altman wrote:
>> How have you confirmed that the issue you are experiencing is the one
>> described in the Nov 2005?
>>
>> do you have a stack trace or a crash dump from the application?
>>
>> Hong Ye wrote:
>>  
>>> latest release KFW 3.2.2.
>>>
>>> Jeffrey Altman wrote:
>>>    
>>>> Hong Ye wrote:
>>>>  
>>>>      
>>>>> Hi,
>>>>>
>>>>> Our authentication application developed using MIT kerberos crashed
>>>>> in multi-thread environment on Windows. I found this post which
>>>>> describes the same problem as we were seeing. The post was dated
>>>>> Nov,2005. Has this problem been resolved in latest Kerberos library.
>>>>> If not, is there work around?
>>>>>
>>>>> "Using the MEMORY credentials cache from multiple threads is not
>>>>> thread-safe and crashes."
>>>>> http://mailman.mit.edu/pipermail/krb5-bugs/2005-November/004061.html
>>>>>
>>>>> Any suggestions are appreciated,
>>>>>
>>>>> Hong
>>>>>
>>>>>             
>>>> What version of KFW are you using?
>>>>
>>>>
>>>>         
>>>     
>
>

--------------ms040007060705090204090601
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX
DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI
zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6
6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe
N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK
3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs
/Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1
vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE
+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA
LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU
lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89
93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo
CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn
5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6
TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze
xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MDQxMzU5NTlaMCMGCSqGSIb3DQEJBDEWBBROWhss
9KJD8f0I3T2nLbHv1MshRDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ
KoZIhvcNAQEBBQAEggEAEXNNee6tzp66dK5qGLhb3aFhHlWJcW8Clox9wP+7dUgAusBB8QWv
YKbteyMV0qBwrKt6O/hY0MWBFJ16Qh6BUZvjHD0CO9i76aoPZUU9Nnht5FKI4BlgS/ZIO9pO
DA1oMUDFA06aA7BEBDy8nb5z92EUMOKMl58tvTCTiPG1nw9m+SPsnf8I999BZ00tEbgWMLS2
+fBONA7rXvqo3ox8A+nZiu9F33XHWNwdoLdxKm+SBsdBrZWdR+DBvYEkVxpgih3abPatLlfi
W14MdOlDjlLIi/aZ2CNtHUT+wk38WvMpsQoD6Q0sdx/60r0BjpFvLkbQMf8XIzY4UYYSiveM
yQAAAAAAAA==
--------------ms040007060705090204090601--


--===============1482063125==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

--===============1482063125==--


home help back first fref pref prev next nref lref last post