Hello,

today I had a glibc error with svn head, which looks like "writing
over an array boundary" to me:

>0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11] pkcs11-global.c:447:C_GetSlotList: 
>doing free
>*** glibc detected *** 
>/home/kde/work/opensc/svn_head/opensc/src/tools/.libs/pkcs11-tool: free(): 
>invalid next size (fast): 0x0000000000629b00 ***
>======= Backtrace: =========
>/lib64/libc.so.6[0x7fe710d42108]
>/lib6Aborted

The glibc abort happens in the function: pkcs11-global:C_GetSlotList
As far as I understand this, the section:(around line 380)


>if ((found = (CK_SLOT_ID_PTR)malloc (sizeof (*found) * 
>sc_pkcs11_conf.max_virtual_slots)) == NULL) {
>               rv = CKR_HOST_MEMORY;
>               goto out;
>}

allocates an array with sc_pkcs11_conf.max_virtual_slots entries. My
printf says that:

>sc_debug(context, SC_LOG_DEBUG_NORMAL,"found 
>2:%d\n",sc_pkcs11_conf.max_virtual_slots);
>0x7fe7120b66f0 12:48:44.132 [opensc-pkcs11] pkcs11-global.c:381:C_GetSlotList: 
>found 2:1

==> 1

But then it writes to this array 5 times:(around line 400)

>if (!tokenPresent || (slot->slot_info.flags & CKF_TOKEN_PRESENT)) {
>       sc_debug(context, SC_LOG_DEBUG_NORMAL,"writing found :%d\n",numMatches);
>/*
>if (numMatches >= sc_pkcs11_conf.max_virtual_slots) {
>  printf("malloc error in found\n");
>  exit(1);
>}
>*/
>found[numMatches++] = slot->id;
        
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:408:C_GetSlotList: writing found :0
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:408:C_GetSlotList: writing found :1
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:408:C_GetSlotList: writing found :2
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:408:C_GetSlotList: writing found :3
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:408:C_GetSlotList: writing found :4
0x7fe7120b66f0 12:48:44.133 [opensc-pkcs11]
pkcs11-global.c:422:C_GetSlotList: was only a size inquiry (5)


Is this the heap corruption detected by glibc?

Maybe I have a broken config file, but can this
be handled somehow without a heap corruption?

regards,

Martin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to