CVE-2026-93156

What it actually does

The rk3288 hash driver ignores the result of polling RK_CRYPTO_HASH_STS after the final DMA transfer; on timeout it proceeds to read stale digest registers and returns success instead of an error.

Why it matters to the business

Systems relying on hardware-accelerated hashing on affected Rockchip SoCs may silently produce or accept incorrect digest values, undermining integrity protections for stored or transmitted data.

How an attack unfolds

An attacker supplies input that causes the hash engine to remain busy after the final DMA; the driver then returns a digest computed from a prior operation, allowing forged integrity tags or signatures to be accepted.

How to fix it

Update to a kernel containing the fix that stores the poll result and returns the timeout error before reading digest registers.

How to confirm the fix worked

Confirm the presence of the poll-result check and early error return in rk_hash_run() in the running kernel source or binary; re-run hash workloads that previously triggered idle timeouts and verify they now fail with timeout.

Typical attack path

1. Identify a process or service using rk3288 hardware hashing on a vulnerable kernel
2. Craft input that triggers prolonged hash-engine busy state after final DMA
3. Force the driver to read stale digest registers and accept the result as valid
4. Use the accepted incorrect digest to bypass integrity or authentication checks

How to detect it

Search kernel logs and driver traces for unexpected success returns from rk_hash_run after idle-timeout conditions; review any application logs showing digest mismatches or integrity failures that resolve after the fix.

What your security team should do

• Apply the upstream fix or vendor kernel update as soon as available
• Where hardware hashing cannot be updated, fall back to software hash implementations for sensitive operations
• Monitor kernel logs for hash-related timeout or error messages on affected platforms