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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
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.