808bits

CKR_DEVICE_MEMORY

PKCS#11 return value · 0x00000031 · decimal 49
hex 0x00000031 decimal 49 name CKR_DEVICE_MEMORY

Storage inside an HSM is small and it is not garbage collected. This code says the token could not find room, and in almost every real case the cause is not the object you were creating but the several thousand nobody ever deleted. It is one of the few PKCS#11 errors that is genuinely a capacity problem, which also makes it one of the few you can predict and avoid.

What the token is reporting

The token could not allocate what the operation needed. Depending on the library that can mean persistent storage for a token object, working memory for an operation, or a per-partition quota on an appliance shared between tenants.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

Token objects have accumulated and nobody deletes them

Every object created with the token attribute set survives restarts, so an application that creates a key per operation and never destroys it will fill a token slowly and then fail all at once. Session keys that should have been session objects are the usual culprit.

Check it: Count the objects on the token and look at their creation dates. A flat count is fine. A count that tracks your request volume is the answer.

Fix: Destroy what you do not need, then fix the code that created it. A key that does not need to outlive the session should never have been a token object in the first place.

Free memory on the token is genuinely low

Tokens report their own free space, and the numbers are usually far smaller than people expect. Reading them turns a guess into a fact.

Check it: Read the token information structure and look at the free public and free private memory fields. Any tool that prints token info will show them, and so will a few lines against the library directly.

A partition quota on a shared appliance

On an HSM partitioned between tenants, the limit that bites is the one configured for your partition rather than the physical capacity of the device. The token looks nearly empty and still refuses to store anything.

Check it: Compare the token’s reported free memory against the partition configuration on the appliance. If they disagree, the quota is the ceiling you are hitting.

The operation needs more working memory than the token has

Large data through a mechanism that must process it entirely inside the boundary can exhaust working memory rather than storage. Libraries that hash in software are not affected, which is why the same call can succeed against one vendor and fail against another.

Check it: Reduce the input size and retry. If a smaller input succeeds while storage stays untouched, this is working memory rather than a full token.

Which calls return it

C_CreateObject, C_GenerateKey, C_GenerateKeyPair, C_CopyObject

What it is not

It is not host memory. If your process were out of memory the library would say so with a different code, and adding RAM to the machine will not help.

Often confused with

  • CKR_DEVICE_ERROR: Some libraries report a full token through the general device fault instead, so a token that is nearly full is worth ruling out even when the code you got was the vague one.

Sources

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.