CVE-2026-97588: s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly
In the Linux kernel, the following vulnerability has been resolved:
s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly
When hardware persistently returns -EBUSY after exhausting retries, the error propagates to cryptofinalizerequest(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using cryptowaitreq() to block indefinitely.
Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation.
Affected Software
Event History
Frequently Asked Questions
Which systems and workloads are exposed to the indefinite wait?
The issue affects Linux kernel s390 crypto operations where a request reaches key conversion and the hardware persistently returns -EBUSY after all retries are exhausted. Callers that use crypto_wait_req() are the ones that can block indefinitely.
What must happen for the failure to occur?
The crypto hardware must continue returning -EBUSY during key conversion even after the kernel exhausts its retries. The persistent -EBUSY is then treated by the crypto API completion wrapper as a queueing status rather than a completed error.
How can an affected system be recognized?
Affected callers using crypto_wait_req() may wait indefinitely because their completion callback is not invoked. The triggering condition is repeated hardware -EBUSY responses during key conversion.
What does the resolution change?
After retry exhaustion, the kernel maps the persistent -EBUSY result to -EIO. This allows the error to propagate and ensures the completion callback is invoked rather than leaving the caller blocked.