Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1685194 - Assertion retrieving CKA_ID that has been explicitiy created as zero-length byte string
Summary: Assertion retrieving CKA_ID that has been explicitiy created as zero-length ...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: softhsm
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-04 15:24 UTC by space88man
Modified: 2019-03-05 03:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github opendnssec SoftHSMv2 issues 449 None None None 2019-03-04 15:24:57 UTC

Description space88man 2019-03-04 15:24:23 UTC
Description of problem:
Create a private key with out CKA_ID explicitly set to zero-length byte string in the template.

Trying  to retrieve the attribute results in the assertion

/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = unsigned char; _Alloc = SecureAllocator<unsigned char>; std::vector<_Tp, _Alloc>::const_reference = const unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
this->size(), true)' failed.



Version-Release number of selected component (if applicable):


How reproducible:
softhsm-2.5.0-2.fc29.x86_64


Steps to Reproduce:
1. Create private key and explicitly set CKA_ID to zero-length byte string
2. Reproducers in the external ticket
3. C_GetAttributeValue on CKA_ID

Actual results:

/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = unsigned char; _Alloc = SecureAllocator<unsigned char>; std::vector<_Tp, _Alloc>::const_reference = const unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)


Expected results:
Able to retrieve the zero-length CKA_ID


Additional info:
1. For public key and certs, there is no issue in retrieving CKA_ID even if explicitly created as zero-length byte string
2. For new private keys without explicit CKA_ID in the template; there is an implicit zero-length CKA_ID and this can be retrieved. But once the CKA_ID is explicitly set, then the error occurs

Comment 1 space88man 2019-03-04 15:30:41 UTC
Problem does not happen on CentOS 7/RHEL 7 with softhsm-2.1.0-2.el7.x86_64

Comment 2 space88man 2019-03-04 15:47:30 UTC
Build from upstream Github develop/2.5.0 with no Fedora localisations

sh autogen.sh
./configure --disable-strict
make

The resulting artifacts works without assertion

Comment 3 space88man 2019-03-05 03:01:23 UTC
TL;DR - taking a reference of the "first" element of a zero-length unsigned char array

Root cause:
when retrieving attributes from sensitive objects(e.g. private keys), the serialized attribute value is first decrypted, but P11Attributes.cpp:343 does not check the return value has size != 0. It takes a reference, &byteString[0], on a zero-length array.

When the library is built with -Wp,-D_GLIBCXX_ASSERTIONS the assertion is triggered.


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