CKR_HOST_MEMORY
In a library written in C this is what a failed allocation turns into, and a modern host almost never fails a small allocation, so a real shortage of memory is the least likely explanation. What reaches a bug report is an allocation sized from a corrupt length field, a leak in a process that has been up for weeks, or a device or connector error that a vendor library chose to file under host memory.
What the token is reporting
The library’s own memory allocation failed. This is the host’s memory, not the token’s storage, which has a separate code. The operation did not run and the library’s state is unchanged.Likely causes
Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.
A size derived from bad input
A length field that was never initialised, a count that overflowed, an attribute length read back as unavailable and then used as a size. The allocation asked for is enormous and fails, and the code looks like the machine ran out of memory.Check it: Log the sizes the library is asked to allocate, or trace the allocation calls. One absurd value is the answer. Check every length field you pass is initialised.
A leak in a long-running process
Sessions opened and never closed, find operations never finalised, attribute buffers that are read and not freed. The process grows until an allocation fails or the library’s own session table does, and the failure lands on whatever call happened to come next.Check it: Watch resident memory over time, and count open sessions through the slot information. Steady growth under steady load is the pattern.
A vendor or device error filed here
Some libraries map an internal memory error of their own client stack, or a connector that could not be set up, onto this code, so it can arrive at initialise on a machine with plenty of memory.Check it: Turn on the library’s debug log. A native error just before the return is the real cause.
The process really is out of memory
A container with a small memory limit, an address space limit set by the shell, or a 32-bit process near its ceiling. Real, but check the others first.Check it: Look at the kernel log and the cgroup or resource limits of the process.
Which calls return it
C_Initialize, C_OpenSession, C_GetAttributeValue, C_FindObjectsInit, C_GenerateKeyPair
What it is not
It is not the token’s storage. A token that has no room for an object reports device memory. It is also not a hint to retry at once, since the state that caused it is still there.Often confused with
CKR_DEVICE_MEMORY: Host versus token. The names are close and the causes have nothing in common.CKR_GENERAL_ERROR: Where some libraries put an allocation failure they did not want to report precisely.CKR_FUNCTION_FAILED: The other catch-all a leak can surface as, once the library's internal tables rather than the allocator give out.
By library
IBM opencryptoki
More than six hundred sites, all the plain allocation-failure kind. In a library that size the code is almost always honest, and almost never seen.OpenSC
The card layer’s out-of-memory error maps to it (misc.c), and most of the library’s own sites are in mechanism registration during initialise. From OpenSC it tends to show up at initialise or on first use of a slot, not mid-operation.YubiHSM 2
The library’s own memory error maps here (util_pkcs11.c), and the initialise function returns it from three places, one of them the building of the connector list. A connector configuration problem at initialise can wear this code.Sources
- PKCS #11 Specification Version 3.2, OASIS. Read 2026-09-10. Used for constant name and numeric value.
Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.