CVE-2026-93159: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
In the Linux kernel, the following vulnerability has been resolved:
crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
The nonblocking RNG path allocates a workdata structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes.
If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated workdata is not usable for producing RNG output and must not remain associated with the hwrng state.
Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data.
Fix this by freeing the pending workdata. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.
Affected Software
Event History
Frequently Asked Questions
What condition is required to trigger the stale state?
An underlying asynchronous I2C transfer must fail in the nonblocking RNG path. The failure callback receives a non-zero status, but the previously allocated work_data was left associated with the hardware RNG state.
What is the effect of a failed transfer before this fix?
Later read attempts can observe the stale rng->priv state and treat it as valid completed RNG data. The issue is an information leak from residual heap-backed work_data rather than usable output from the failed request.
What should be prioritized when assessing exposure?
Focus on systems using the atmel-sha204a hardware RNG through its nonblocking asynchronous I2C path, particularly where I2C transfer errors can occur. The described issue is reached only after an I2C transaction reports an error.