UBUNTU-CVE-2026-93156: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rkhashrun() waits for RKCRYPTOHASHSTS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.
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 - Compensating control
In rk_hash_run(), store the RK_CRYPTO_HASH_STS idle poll result and, if it indicates a timeout, finalize the ahash request with the timeout error before reading the digest registers.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected Ubuntu kernel package families listed are linux-riscv, linux-realtime, linux-azure, linux-gcp, linux-azure-fde, linux-gke, linux-hwe-edge, and linux-gkeop. The issue is in the RK3288 crypto hash driver, so exposure depends on use of that driver and its hash engine.
What condition triggers the incorrect behavior?
A hash request reaches its final DMA transfer and the hash engine fails to become idle before the driver's polling timeout. The vulnerable driver ignores that timeout and completes the request using digest registers instead of reporting the timeout error.
How can I determine whether a hash operation may have been affected?
Look for hash operations using the RK3288 crypto driver where the hardware did not become idle after the final DMA transfer. On affected kernels, such a timeout can be reported as a successful request, so successful completion alone does not rule out the condition.
What is the mitigation when an update cannot be applied immediately?
The provided information does not identify a configuration workaround. Reducing reliance on the RK3288 hash engine is the only mitigation implied by the affected component; the resolved behavior is to fail timed-out requests rather than use the digest registers.