What were you trying to do that didn't work?

The GNUTLS docs about thread safety have a list of conditions which, if satisfied, are expected to allow a gnutls_session_t object to be used for concurrent I/O from 2 threads (ie for parallel gnutls_record_send & gnutls_record_recv, but nothing else):

https://gnutls.org/manual/gnutls.html#Thread-safety

QEMU follows this guidance, but despite that, we find that GNUTLS will corrupt session state due to TLS 1.3 automatic re-keying

This same issue, with greater details is also reported upstream:

https://gitlab.com/gnutls/gnutls/-/issues/1717

What is the impact of this issue to you?

When QEMU live migration has its "postcopy" feature enabled, it uses a bidirectional TCP channel and thus when TLS is enabled for migration, QEMU wll have two threads using the gnutls_session_t - one sending and one receiving.

If the live migration stays in "precopy" phase for long enough a TLS 1.3 rekey will get initiated. When QEMU is then told to switch to "postcopy" phase triggering recvs on the source QEMU, the TLS session will fail with "Decryption has failed."

Please provide the package NVR for which the bug is seen:

gnutls-3.8.3-6.el9.x86_64

How reproducible is this bug?:

Slightly non-deterministic, but usually possible to trigger when TLS 1.3 is enabled with a cipher that requires rekeying

Steps to reproduce

1. Save the demo program tlsrekey.c
2. gcc -o tlsrekey tlsrekey.c -lgnutls -DSERVER_MANUAL_REKEY=1
3. ./tlsrekey

As an alternative to "SERVER_MANUAL_REKEY", either "SERVER_AUTO_REKEY" or "CLIENT_AUTO_REKEY" or both can be defined at build time - this is much slower to reproduce as auto-rekeying waits for 16million records, where as the demo program manual rekeying triggers every 2 seconds. The errors observed as slightly different with CLIENT_AUTO_REKEY but likely the same root cause.

Expected results

1879: client sender
1880: server echo
1878: client receiver
1880: manual key update
1880: manual key update
1880: manual key update
1880: manual key update
..keying without errors forever..

Actual results

1879: client sender
1880: server echo
1878: client receiver
1880: manual key update
1880: echo recv: Decryption has failed.