tcti_device_receive "Cannot allocate memory" and Esys bad sequence errors during single TLS handshake

[manishtwari]

We are trying to use the TPM to securely store our private key instead of keeping it on the file system.
Then, during data transfer, we use mutual TLS (mTLS) so both systems authenticate each other using certificates and private keys that are stored inside the TPM.

Both of our systems run stunnel for TLS and use rsync over that TLS channel to send data.
So it’s basically:

rsync (data) → stunnel (TLS + TPM key) → network → stunnel → rsync

While doing this, we are seeing repeated TPM failures

2025.11.09 07:24:49 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate
ERROR:tcti:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-tcti/tcti-device.c:198:tcti_device_receive() Failed to get response size fd 13, got errno 12: Cannot allocate memory
ERROR:esys:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-esys/api/Esys_ContextLoad.c:283:Esys_ContextLoad_Finish() Received a non-TPM Error
ERROR:esys:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-esys/api/Esys_ContextLoad.c:93:Esys_ContextLoad() Esys Finish ErrorCode (0x000a000a)
ERROR:esys:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-esys/esys_iutil.c:1250:iesys_check_sequence_async() Esys called in bad sequence.
ERROR:esys:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-esys/api/Esys_SequenceUpdate.c:74:Esys_SequenceUpdate() Error in async function ErrorCode (0x00070007)
2025.11.09 07:24:53 LOG7[0]: TLS alert (write): fatal: decrypt error
ERROR:esys:/usr/src/debug/tpm2-tss/4.1.3/src/tss2-esys/api/Esys_FlushContext.c:66:Esys_FlushContext() Error in async function ErrorCode (0x00070007)
2025.11.09 07:24:53 LOG3[0]: error queue: tls_process_cert_verify@/usr/src/debug/openssl/3.4.1/ssl/statem/statem_lib.c:582: error:0A00007B:lib(20)::reason(123)
2025.11.09 07:24:53 LOG3[0]: error queue: :-1: error:4000000E:lib(128)::reason(14): esapi:Function called in the wrong order
2025.11.09 07:24:53 LOG3[0]: error queue: :-1: error:40000013:lib(128)::reason(19): tcti:IO failure
2025.11.09 07:24:53 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2025.11.09 07:24:53 LOG7[0]: Service [sibling_system] finished (0 left)
rsync: [sender] safe_read failed to read 1 bytes: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(283) [sender=3.4.1]

After this, the TLS handshake fails

We even tried running a background script that flushes all transient, loaded, and session contexts every 10 milliseconds:

while true; do
  tpm2_flushcontext -t
  tpm2_flushcontext -s
  tpm2_flushcontext -l
  sleep 0.01
done

But even with this running, the same error we hitting up

Steps to Reproduce

1. Store an ECC key in TPM and make it persistent.
2. Configure stunnel to use that TPM key via OpenSSL tpm2 provider.
3. Run a single rsync transfer through the stunnel mTLS setup.
4. Observe TLS failure and the above TPM/TSS logs.

I’m not sure why this happens
Would appreciate any guidance or fix currently I’m completely stuck here.
@williamcroberts

[williamcroberts]

Could you give me:

1. The details of your system, OS and software versions?
2. A script that does the setup

This way I can try and reproduce

[manishtwari]

I will get back with details

[manishtwari]

Hardware: Embedded ARM (armv7l)
Operating System: Linux (Yocto/OpenEmbedded-based embedded build)

Component - Version
tpm2-tss - 4.1.3
tpm2-tools - 5.7
tpm2-openssl - 1.3.0
OpenSSL - 3.4.1
stunnel - 5.75

You can find the setup and script here
https://github.com/manishtwari/tpm-scripts

[williamcroberts]

By any chance is it in big endian mode or is it little endian?

[manishtwari]

I checked it's in little endian mode

[williamcroberts]

What's your kernel version? I wonder if it is related to this patch: torvalds/linux@2e8e4c8

That fix is on kernel versions 5.18 and above IIUC.

[williamcroberts]

Also, are you using a resource manager or is your application the one using the device TCTI directly? If so, what device file are you opening, is it /dev/tpm0 or /dev/tpmrm0?

[manishtwari]

Kernel: 6.12.27 so it’s well above 5.18
TCTI/RM: Using the device TCTI with the kernel Resource Manager- /dev/tpmrm0
verified via /proc//fd during the TLS handshake (shows a symlink to /dev/tpmrm0)

[williamcroberts]

Ok i am still setting up a yocto environment based on the ci/qemuarm-secureboot.yml from kas. Do you know if your bug reproduces within that environment?

[manishtwari]

Thanks, I haven’t tried reproducing it in the ci/qemuarm-secureboot.yml environment, so I’m not sure about that setup.
However today, I made a change to include tpm2-abrmd in the image and used its TCTI endpoint instead of the kernel RM
with this setup, the mTLS operation completed successfully with no Cannot allocate memory error.

[williamcroberts]

Thanks, I haven’t tried reproducing it in the ci/qemuarm-secureboot.yml environment, so I’m not sure about that setup. However today, I made a change to include tpm2-abrmd in the image and used its TCTI endpoint instead of the kernel RM with this setup, the mTLS operation completed successfully with no Cannot allocate memory error.

I wanted to ask you do that, but I wasn't sure how hard it would be to setup tpm2-abrmd. This smelled like a resource manager bug/limitation. If I remember correctly, the workspace within the kernel only allowing for 3 saved contexts, I wonder if that is it. I'm not familiar with the stunnel internals. It looks like the failure is in stunnel, so maybe it's doing something odd that the kernel RM cannot handle. @jarkkojs do you have any insight?

[williamcroberts]

Also, it seems to be around context saving and loading, which my guess is coming from the tpm2-openssl provider, @gotthardp perhaps you have seen this, or have some insight? It seems that both the engine and provider make use of ContextSave and ContextLoad around duplicating a sequence handle, I have no idea why, but assume that's right since both have it. I wonder if this is because the stunnel use of openssl is causing /dev/tpmrm0 to be opened multiple times, so things saved can't be loaded?

@manishtwari if you run it in something like strace, or do the logs show a sequence of ContextSave, a close of /dev/tpmrm0, an open of /dev/tpmrm0 and then followed by the context load?

[manishtwari]

Sure, I’ll give it a try.
But at the moment, I’ve got a few other high-priority items to focus on, so I won’t be able to continue the investigation right away. I’ll revisit this thread and try the steps you mentioned (including tracing the context save/load behavior) once I get a chance likely in about two weeks. I’ll be back with more data then.

[jarkkojs]

Thanks, I haven’t tried reproducing it in the ci/qemuarm-secureboot.yml environment, so I’m not sure about that setup. However today, I made a change to include tpm2-abrmd in the image and used its TCTI endpoint instead of the kernel RM with this setup, the mTLS operation completed successfully with no Cannot allocate memory error.

I wanted to ask you do that, but I wasn't sure how hard it would be to setup tpm2-abrmd. This smelled like a resource manager bug/limitation. If I remember correctly, the workspace within the kernel only allowing for 3 saved contexts, I wonder if that is it. I'm not familiar with the stunnel internals. It looks like the failure is in stunnel, so maybe it's doing something odd that the kernel RM cannot handle. @jarkkojs do you have any insight?

Maybe I'm missing the context here but has it been proven that error spuns from kernel? Note, I did not read the issue throughly so please correct me if there is need :-)

[williamcroberts]

Thanks, I haven’t tried reproducing it in the ci/qemuarm-secureboot.yml environment, so I’m not sure about that setup. However today, I made a change to include tpm2-abrmd in the image and used its TCTI endpoint instead of the kernel RM with this setup, the mTLS operation completed successfully with no Cannot allocate memory error.

I wanted to ask you do that, but I wasn't sure how hard it would be to setup tpm2-abrmd. This smelled like a resource manager bug/limitation. If I remember correctly, the workspace within the kernel only allowing for 3 saved contexts, I wonder if that is it. I'm not familiar with the stunnel internals. It looks like the failure is in stunnel, so maybe it's doing something odd that the kernel RM cannot handle. @jarkkojs do you have any insight?

Maybe I'm missing the context here but has it been proven that error spuns from kernel? Note, I did not read the issue throughly so please correct me if there is need :-)

That's what we're trying to determine. It works with the user space RM and not the kernel RM. I'm trying to figure out if this is a bug or a feature gap within the in-kernel RM.