Handle attribute size -1 gracefully.

[ximon18]

I ran into a problem with the NitroKey NetHSM Docker image when using Cryptoki v0.9.0 as a result of a call to C_GetAttributeValue that unexpectedly returned -1 as the uiValueLen (according to pkcs11spy).

The Cryptoki library panicked like so:

thread 'nameshed-worker' panicked at /home/ximon/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cryptoki-0.9.0/src/session/object_management.rs:512:39:
capacity overflow
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: alloc::raw_vec::capacity_overflow
   3: alloc::raw_vec::handle_error
   4: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   5: cryptoki::session::object_management::<impl cryptoki::session::Session>::get_attributes
   6: nameshed_hsm_relay::pkcs11::operations::get::get_public_key
   7: nameshed_hsm_relay::client_request_handler::process_request
   8: nameshed_hsm_relay::client_request_handler::handle_client_requests::{{closure}}::{{closure}}
   9: tokio::runtime::task::core::Core<T,S>::poll
  10: tokio::runtime::task::raw::poll
  11: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

pkcs11spy showed:

26: C_GetAttributeValue
P:1957429; T:0x139635248244416 2025-07-22 16:39:49.996
[in] hSession = 0x1
[in] hObject = 0x1
[in] pTemplate[1]:
    CKA_EC_POINT          0000000000000000 / 0
[out] pTemplate[1]:
    CKA_EC_POINT          0000000000000000 / -1
Returned:  0 CKR_OK

As -1 is interpreted for an unsigned value such as usize used in the code as the maximum value, applying the workaround in this PR resolved the issue.

While -1 is not a legal value, in its positive form it doesn't seem to strictly violate the PKCS#11 v2.40 specification which states:

Otherwise, if the length specified in ulValueLen is large enough to hold the value of the specified attribute for the object, then that attribute is copied into the buffer located at pValue, and the ulValueLen field is modified to hold the exact length of the attribute.

But of course the value is too large to be usable.

[wiktor-k]

Okay, sounds sensible. I think I'd add a comment that usize::MAX is in reality -1 underflowed. I'll ping our resident spec expert: @Jakuje ;)

[wiktor-k]

Btw @ximon18 have you created an issue on the Nitrokey pkcs11 repo? Maybe that's something they could address there too...

[Jakuje]

The -1 size is usize::MAX and means CK_UNAVAILABLE_INFORMATION, which means the token does not want to give you the value for some reason:

https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/pkcs11-spec-v3.1-os.html#_Toc111203287

If it is printed as -1, its an pkcs11-spy issue -- please open an issue/PR to https://github.com/OpenSC/OpenSC

[Jakuje]

I think fixed this in 0.10 with this commit, which is not yet in 0.9 branch: b8ba7b1 -- @ximon18 can you try if you still experience this issue in 0.10?

[ximon18]

Hmm, I could swear I checked for a newer version of Cryptoki first, my apologies.

[ximon18]

I think fixed this in 0.10 with this commit, which is not yet in 0.9 branch: b8ba7b1 -- @ximon18 can you try if you still experience this issue in 0.10?

I will test with 0.10.0, but that will have to wait till later tonight or tomorrow.

[ximon18]

It works with 0.10.0, sorry for the noise!