Here is a hypothetical application which may have similar problem.
(1) It is a multi threaded application using gpgme, forking another process (possibly, exec).
(2) One of threads invokes gpgme_new, gpgme_op_import and gpg_op_verify.
(3) When the control goes to gpgme_op_* then gpgme_io_spawn by a thread A, another thread B forks a process.
(3-1) While the thread A is polling pipe I/O, forked process holds pipe file descriptors too.
(3-2) Until the forked process exists, pipe I/O polling by the thread A continues (because pipe's other end is still active).

I don't know if it is related to this particular case, but I found a possible race condition in _gpgme_io_pipe.
Between pipe and fcntl with FD_CLOEXEC, another thread may fork a process which keeps running.
It would be good to use pipe2 here:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pipe.html

Another possible cause is... gpgme uses closefrom in GNU C library, if available. if it doesn't work well, it would be possible invoked gpg keeps waiting its input.

Here is my observation.

The issue is the routines of regcomp, regexec, regerror and regfree are in C library and the sanitizer library replaces them (and it's not compatible for the use case of GnuPG).

Another possible change will be use of KEM interface for gpgsm.
Not high priority, but for long term code maintenance.

Done by T7649: gnupg: Use KEM interface for encryption/decryption

Thank you.

Clean up finished by rG681d75404300: gpg,agent: Clean up around using ECC KEM.
Tested by make check and decrypting tests/openpgp/samplemsgs/pqc-sample-*.enc.asc.

Pushed all changes needed. Actually, agent side too.
Clean up will be done.

Looking the FIPS 204 document, using the following functions (API) is good:

For prompting, I pushed a fix in rG45a11327f3bd: agent: Support the use case of composite PQC for prompting.
Thank you for testing.

Thank you for the concrete test case, it helps me.

NIST has an initial public draft for KEM: https://csrc.nist.gov/pubs/sp/800/227/ipd

It's in 1.11.1.

Included in 1.11.1.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

In libgcrypt/cipher/ecc-ecdsa.c, we have:

mpi_mulm (s, k_1, sum, ec->n);    /* s = k^(-1)*(hash+(d*r)) mod n */

doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

IIUC, it's GCC 8 which starts the support of __nonstring__ attribute.

Fix pushed by: rG1ed8b0e7b403: dirmngr: Fix libdns with 127.0.0.1.

For Linux kernel, once, it was proposed:
https://patchwork.ozlabs.org/project/netdev/patch/1490748756.24891.27.camel@edumazet-glaptop3.roam.corp.google.com/

Another problem with same cause (possibly) is reported: https://lists.gnupg.org/pipermail/gnupg-devel/2025-April/035845.html

Pushed all changes to master.